C++ "setf" Scientific Application "floatfield"

//4.  Program shows the application scientific

int main()

{

   cout<   cout.width(20);

   cout.setf(ios::scientific,ios::floatfield);

   cout.fill('*');

   cout<

}

C++ "setf " Function

//2. Program shows the application of setf function right padding


int main()

{

   cout.width(20);

   cout.setf(ios::right,ios::adjustfield);

   cout.fill('*');

   cout<<"IT";

}

C ++ "setf" function for left padding

/* This file contains program related to console input and output */

#include 

#include

// 1. Program shows the application of setf function for left padding

int main()

{

   cout.width(20);

   cout.setf(ios::left,ios::adjustfield);

   cout.fill('*');

   cout<<"IT";

}

C++ Multilevel Inheritance

* C++ program to demonstrate example of multilevel inheritance.*/

Ref: Kamthane.

#include

using namespace std;

//Base Class : class A
class A
{
    private:
        int a;
    public:
        void get_a(int val_a)
        { 

           a=val_a; 

         }
       
       void disp_a(void)
        {  

           cout << "Value of a: " << a << endl;  

        }
};


class B: public A
{
    private:
        int b;
    public:
        void get_b(int val_a, int val_b)
        {

              //assign value of a by calling function of class A
            get_a(val_a);     
            b=val_b;
        }


        void disp_b(void)
        {
            //display value of a
            disp_a();
            cout << "Value of b: " << b << endl;
        }
};


//Here class C is derived class and B is Base class


class C: public B
{
    private:
        int c;
    public:
        //assign value of a from here
        void get_c(int val_a, int val_b,int val_c)
        {
            /*** Multilevel Inheritance ***/
            //assign value of a, b by calling function of class B and Class A
            //here Class A is inherited on Class B, and Class B in inherited on Class B
            get_b(val_a,val_b);
            c=val_c;
        }
       
        void disp_c(void)
        {


            disp_b(); //display value of a and b using disp_b()

            cout << "Value of c: " << c << endl;
        }
};

int main()
{
    //create object of final class, which is Class C


    C objC;


    objC.get_c(10,20,30);
    objC.disp_c();


    return 0;
}

C++ Single Level Inheritance

/*C++ program to demonstrate example of private simple inheritance.*/

Ref: Kamthane



#include
using namespace std;


class A
{   

    private:
        int a;
    protected:
        int x;      //can access by the derived class
    public:
        void setVal(int v)

        { 

           x=v; 

        }
};


class B:private A
{
    public:
        void printVal(void)
        {  

           //accessing public member function here //protected data member direct access here
            setVal(10);  

            cout << "value of x: " << x << endl;
        }
};


int main()
{   

       //derived class creation


        B objB; 
        objB.printVal();        return 0;

}

Java Practise Program List

1.  Practice - 1   - Premlimnary Level
2.  Practice  -2   - Advance Level

Jhansi Ki Rani | Rani Lakshmi bai | 3d Animation Song 2017 | Cordova Joy...

Dimensional Modeling Basics

2.1 Dimensional Modeling Basics    

 Dimensional modeling gets its name from the business dimensions we need to incorporate into the logical data model. It is a logical design technique to structure the business dimensions and the metrics that are analyzed along these dimensions. This modeling technique is intuitive for that purpose. The model has also proved to provide high performance for queries and analysis. The multidimensional information package diagram we have discussed is the foundation for the dimensional model. Therefore, the dimensional model consists of the specific data structures needed to represent the business dimensions. These data structures also contain the metrics or facts.

     To build a dimensional database, you start with a dimensional data model. The dimensional data model provides a method for making databases simple and understandable. You can conceive of a dimensional database as a database cube of three or four dimensions where users can access a slice of the database along any of its dimensions. To create a dimensional database, you need a model that lets you visualize the data.

     Suppose your business sells products in different markets and evaluates the performance over time. It is easy to conceive of this business process as a cube of data, which contains dimensions for time, products, and markets.   Shows this dimensional model. The various intersections along the lines of the cube would contain the measures of the business. The measures correspond to a particular combination of product, market, and time data.

FIGURE – 2.1: (A Dimensional Model of a Business That Has Time, Product and     Market Dimensions)

     Another name for the dimensional model is the star-join schema. The database designers use this name because the diagram for this model looks like a star with one central table around which a set of other tables are displayed. The central table is the only table in the schema with multiple joins connecting it to all the other tables. This central table is called the fact table and the other tables are called dimension tables. The dimension tables all have only a single join that attaches them to the fact table, regardless of the query.  shows a simple dimensional model of a business that sells products in different markets and evaluates business performance over time.

FIGURE – 2.2: (A Typical Dimensional Model)

2.2 Data Warehousing - Fact and Dimension Tables

     Data warehouses are built using dimensional data models which consist of fact and dimension tables. Dimension tables are used to describe dimensions; they contain dimension keys, values and attributes. For example, the time dimension would contain every hour, day, week, month, quarter and year that has occurred since you started your business operations. Product dimension could contain a name and description of products you sell, their unit price, color, weight and other attributes as applicable.

    Dimension tables are typically small, ranging from a few to several thousand rows. Occasionally dimensions can grow fairly large, however. For example, a large credit card company could have a customer dimension with millions of rows. Dimension table structure is typically very lean, for example customer dimension could look like following:

Table – 1 (Customer Dimension)

Customer_key

Customer_city

Customer_state

Customer_country

    

Although there might be other attributes that you store in the relational database, data warehouses might not need all of those attributes. For example, customer telephone numbers, email addresses and other contact information would not be necessary for the warehouse. Keep in mind that data warehouses are used to make strategic decisions by analyzing trends. It is not meant to be a tool for daily business operations. On the other hand, you might have some Reports that do include data elements that isn’t necessary for data analysis.

     Most data warehouses will have one or multiple time dimensions. Since the warehouse will be used for finding and examining trends, data analysts will need to know when each fact has occurred. The most common time dimension is calendar time. However, your business might also need a fiscal time dimension in case your fiscal year does not start on January 1st as the calendar year.

      Most data warehouses will also contain product or service dimensions since each business typically operates by offering either products or services to others. Geographically dispersed businesses are likely to have a location dimension.

      Fact tables contain keys to dimension tables as well as measurable facts that data analysts would want to examine. For example, a store selling automotive parts might have a fact table recording a sale of each item. The fact table of An educational entity could track credit hours awarded to students. A bakery could have a fact table that records manufacturing of various baked goods.

      Fact tables can grow very large, with millions or even billions of rows. It is important to identify the lowest level of facts that makes sense to analyze for your business this is often referred to as fact table "grain". For instance, for a Healthcare billing company it might be sufficient to track revenues by month; daily and hourly data might not exist  or might not be relevant. On the other hand, the assembly line warehouse analysts might be very concerned in number of defective goods that were manufactured each hour. Similarly a marketing data warehouse might be concerned by the activity of a consumer group with a specific income-level rather than purchases made by each individual.

2.2.1 Fact Table 

Facts:  A fact is a measurement captured from an event (transaction) in the marketplace. It is the raw materials for knowledge – observations.  A customer buys a product at a certain location at a certain time. When the intersection of these four dimensions occurs, a sale is made. The sale is describable as amount of dollars received, number of items sold, weight of goods shipped, etc. – a quantity that can be added to other sales similar in definition. Thus, a meaningful and measurable event of significance to the business occurs at the intersection point of business dimensions. It is the fact. We use the fact to represent a business measure. A data warehouse fact is defined as an intersection of the dimensions constituting the basic entities of the business transaction. It is not easy to show the intersection of more than three dimensions in a diagram, but facts in a data warehouse may originate from many dimensions.

Fact Table: A fact table is used in dimensional model in data warehouse design. A fact table is found at the center of a star schema or snowflake schema surrounded by dimension tables. A fact table consists of facts of a particular business process e.g., sales revenue by month by product. Facts are also known as measurements or metrics. A fact table record captures a measurement or a metric.

Example of fact table:

     In the schema below, we have fact table FACT_SALES that has a grain which gives us a number of units W sold by date, by store and by product. All other tables such as DIM_DATE, DIM_STORE and DIM_PRODUCT are dimensions tables. This schema is known as star schema.   

Here is overview of four steps to design a fact table described by Kimball:

1. Choosing business process to model – The first step is to decide what business process to model by gathering and understanding business needs and available data
2. Declare the grain – by declaring a grain means describing exactly what a fact table record represents
3. Choose the dimensions – once grain of fact table is stated clearly, it is time to determine dimensions for the fact table.
4. Identify facts – identify carefully which facts will appear in the fact table.

FIGURE – 2.3: (Fact Table with Star Scheme)

2.2.2 Dimensional Table 

     A dimension is a structure, often composed of one or more hierarchies, that categorizes data. Dimensional attributes help to describe the dimensional value. They are normally descriptive, textual values. Dimension tables are generally small in size as compared to fact table.

     Hierarchies and categories are included in the information packages for each dimension.  Let us examine the product dimension. Here, the product is the basic automobile. Therefore, we include the data elements relevant to product as hierarchies and categories. These would be model name, model year, package styling, product line, product category, exterior color, interior color, and first model year. Looking at the other business dimensions for the auto sales analysis, we summarize the hierarchies and categories for each dimension as follows:

1.      Product: Model name, model year, package styling, product line, product category, exterior Color, interior color, first model year.

2.      Dealer: Dealer name, city, state, single brand flag, date first operation.

3.      Customer demographics: Age, gender, income range, marital status, household size,

             Vehicles owned, home value, own or rent.

4.      Payment method: Finance type, term in months, interest rate, agent.

5.      Time: Date, month, quarter, year, day of week, day of month, season, holiday flag Let us go back to the hotel occupancy analysis. We have included three business dimensions. Let us list the possible hierarchies and categories for the three dimensions.

6.      Hotel: Hotel line, branch name, branch code, region, address, city, state, Zip Code, Manager, construction year, renovation year

7.      Room type: Room type, room size, number of beds, type of bed, maximum occupants, Suite, refrigerator, kitchenette

8.      Time: Date, day of month, day of week, month, quarter, year, holiday flag.

Types of Meta Data

Types of Meta Data (According to Arun K. Pujari):

1.7.1.1 Build Time Meta Data

At the time of data DWH designing and building, the metadata that we generate can be termed as build time meta data. This metadata links business and Ware house terminology and describe the data technical structure. IT is most detailed and exact type of meta data and is used extensively by ware house designer, developer and administrator.

1.7.1.2 Usage Meta Data

When the ware house is in production, usage meta data, which is derived from built time meta data is an important tool for users and data administrator.

1.7.1.1 Control Meta Data

This metadata is used by databases and other tools to manage their own operation. Control metadata are used by system programmer only. It provides vital information about the timelines of ware house data and helps user track the sequence and timing of ware events.

Ex: Suppose a copy of build time meta data catalog I maintained DBMS for the internal representation. This will be called control metadata.

Meta Data

     The first image most people have of the data warehouse is a large collection of  historical, integrated data. While that image is correct in many regards, there is another  very important element of the data warehouse that is vital - metadata.

      Metadata is data about data. Metadata has been around as long as there have been  programs and data that the programs operate on. Figure 1 shows metadata in a simple form.

     While metadata is not new, the role of metadata and its importance in the face of the data warehouse certainly is new. For years the information technology professional has worked in the same environment as metadata, but in many ways has paid little attention to metadata. The information professional has spent a life dedicated to process and functional analysis, user requirements, maintenance, architectures, and the like. The role of metadata has been passive at best in this milieu. 

    But metadata plays a very different role in data warehouse. Relegating metadata to a backwater, passive role in the data warehouse environment is to defeat the purpose of data warehouse. Metadata plays a very active and important part in the data warehouse environment.

     The reason why metadata plays such an important and active role in the data warehouse environment is apparent when contrasting the operational environment to the data warehouse environment insofar as the user community is concerned.

      It serve to identify the contents and location of data in the ware house metadata us bridge between the DWH and decision support system application. Meta data is needed to provide an unambiguous interpretation. Metadata provide a catalogue of data in the DHW and pointer to this data.  Meta data is used to building, maintaining, managing, and using DWH.

Meta Data repository should contain:

1.      A description of the structure of the DWH. This includes  ware house schemes, view, dimensions, hierarchies and derived data definition, data marts etc.

2.      Operational meta data such as data linkage, currency of data and monitoring information.

3.      Summarization processes which include dimension definition. Data on granularity partitions, summary measure etc.

4.      Detail of data source which includes source databases and their content, gateway description, a data partitions, data extractions etc.

5.      Data related to system performance.

6.      Business meta data, which includes business terms and definition, data owner ship information and changing policies.

Data Mart

      A data mart is a simple form of a data warehouse that is focused on a single subject (or functional area), such as Sales, Finance, or Marketing. Data marts are often built and controlled by a single department within an organization. Given their single-subject focus, data marts usually draw data from only a few sources. The sources could be internal operational systems, a central data warehouse, or external data.

1.6.1 Dependent and Independent Data Mart

     There are two basic types of data marts: dependent and independent. The categorization is based primarily on the data source that feeds the data mart. Dependent data marts draw data from a central data warehouse that has already been created. Independent data marts, in contrast, are standalone systems built by drawing data directly from operational or external sources of data, or both.

     The main difference between independent and dependent data marts is how you populate the data mart; that is, how you get data out of the sources and into the data mart. This step, called the Extraction-Transformation-and Loading (ETL) process, involves moving data from operational systems, filtering it, and loading it into the data mart.

     With dependent data marts, this process is somewhat simplified because formatted and summarized (clean) data has already been loaded into the central data warehouse. The ETL process for dependent data marts is mostly a process of identifying the right subset of data relevant to the chosen data mart subject and moving a copy of it, perhaps in a summarized form.

With independent data marts, however, you must deal with all aspects of the ETL process, much as you do with a central data warehouse. The number of sources is likely to be fewer and the amount of data associated with the data mart is less than the warehouse, given your focus on a single subject.

     The motivations behind the creation of these two types of data marts are also typically different. Dependent data marts are usually built to achieve improved performance and availability, better control, and lower telecommunication costs resulting from local access of data relevant to a specific department. The creation of independent data marts is often driven by the need to have a solution within a shorter time.

1.6.2 Difference between Data Ware House and Data Mart

Table A Differences Between a Data Warehouse and a Data Mart

Category	Data Warehouse	Data Mart
Scope	Corporate	Line of Business (LOB)
Subject	Multiple	Single subject
Data Sources	Many	Few
Size (typical)	100 GB-TB+	< 100 GB
Implementation Time	Months to years	Months