Tag: Case

SQL Queries

by Joydeep MDatabaseLeave a Comment on SQL Queries

 👉  To give a table, or a column in a table, a temporary name we can use Alias:

Syntax: SELECT "column_name" AS "column_Alias" FROM "table_name";

For example we have a table with column_name as “SNo” , “Country” and “Capital” and we want to update it as “Serial Number” , “State” and “Country_Capital then we will run the following command:

👉 To count the number of rows in the table:

Syntax: SELECT COUNT(column_name) AS (alias_name) FROM table_name;

For example we want to count number of orders placed by a particular customer from customer_table:

This will show the count of numbers of order places by the customer id “CG-1234′ and the products ordered.

👉 To add the values in a columns we use Sum command:

Syntax: SELECT SUM (column_name) FROM table_name;

For example we want to add the profit amount from the sales table:

👉 To find out an average for a column in the table:

Syntax: SELECT AVG (column_name) FROM table_name;

For example we need to find the average age of the customers from customer table:

👉To find the minimum and the maximum value in a table:

  • Minimum
SELECT MIN (column_name) FROM table_name;

For example we want to find the minimum order sale made for a product from sales table:

  • Maximum
SELECT MAX (column_name) FROM table_name;

For example we want to find the maximum order sale made for a product from sales table:

👉 To groups rows that have the same values into summary rows, like “find the number of customers in each region” we use GROUP BY statement. The GROUP BY statement is often used with aggregate functions (COUNT(), MAX(), MIN(), SUM(), AVG()) to group the result-set by one or more columns.

Syntax: SELECT "column_name","function-type" (column_name) FROM table_name Group By "column-name";

For example we need to find the number orders places in each region in the table:

👉 To make conditions for aggregate functions we use HAVING clause. The difference between Having clause and Where clause is that we cannot make conditions in aggregate functions whereas we can make conditions in aggregate functions using Having clause.

Syntax: SELECT column_name, AGGREGATE FUNCTION column_name FROM tables GROUP BY (column1) HAVING condition;

For example we have some set of customers in four regions and we want to see in which region the count of customers is more than 200. In this scenario we will use the HAVING clause and set a condition of count more than 200.

This command will show the count of customers in the regions where it is more than 200.

👉 To go through a condition and return a value when the first condition is met (like an if-then-else statement) “CASE” statement is used. So, once a condition is true, it will stop reading and return the result. If no conditions are true, it returns the value in the ELSE clause.

Syntax: SELECT * CASE WHEN condition THEN result ELSE result END;
Tagged : / / / / / / /

General SCM Interview Questions

by scmgalaxy KInterview Questions & AnswersLeave a Comment on General SCM Interview Questions

The previous chapters outlined the state of CM technology from the standpoint of a spectrum of concepts underlying automated CM, and from the standpoint of the reflection of some of these concepts in commercial CM products. Clearly, no CM product supports all CM concepts; similarly, not all CM concepts are necessary in the support of all possible end-user requirements. That is, different CM tools (and the concepts which underlie these tools) may be required by different organizations or projects, or within projects at different  phases of the software development life cycle. This observation, coupled with the observed,continuing industry effort to adopt computer-aided software engineering (CASE) tools, leads us to conclude that integration is key to providing automated CM support in software development environments.
In this chapter we define what we mean by integration by way of a three-level model of integration. We illustrate where CM integration fits into this three-level model.  e then describe the advantages and disadvantages of current approaches to achieving integration in  software development environments. We close with a brief discussion on the relationship between future integration technology and the three levels of integration.

CM Services in Software Environments: A Question of Integration

There is no concensus regarding where CM services should reside in software environment architectures, despite the diversity of approaches that have been explored. For example, CM services have been offered via:

· Tools such as RCS, SCCS, CCC.
· Operating system extensions at the file-system level such as DSEE and NSE.
· Shared data models such as in the CIS specifications [18] and the PCTE PACT [53] environment.

A further complication is the emergence of a robust CASE tool industry, wherein many popular CASE tools provide their own tool-specific repository and CM services. As a result, CM functions are increasingly provided by, and distributed across, several CASE tools in an environment.
We have found it useful to think of integration in terms of a three-level model. This model, illustrated in Figure 5-1, corresponds to the ANSI/SPARC [48] three-schema  pproach used to describe database architectures. A useful intuition is that this correspondence is more than accidental. The bottom level of integration, called “mechanism” integration, corresponds to the ANSI/SPARC physical schema level. Mechanism integration addresses the implementation aspects of software integration, including, but not limited to: software interfaces provided by the environment infrastructure, e.g., operating system or environment framework interfaces;

software interfaces provided by individual tools in the environment; and architectural aspects of the tools, such as process structure (e.g., client/server) and data management structure (derivers, data dictionary, database). In the case of CM, mechanism integration can refer to integration with CM systems such as SCCS, RCS, CCC and DSEE; and CM implementation aspects such as transparent repositories and other operating-systems level CM services.

The middle level of integration, called “services” integration, corresponds to the ANSI/SPARC logical schema level. Services refers to the high-level functions provided by tools, and integration at this level can be regarded as the specification of how services can be related in a coherent fashion. In the case of CM, these services refer to elements of the spectrum of concepts discussed in chapter 3, e.g., workspaces and transactions, and services integration constitutes a kind of unified model of CM services.

The top level of integration, called “process” integration, corresponds to the ANSI/SPARC external schema (also called “end-user”) level. Process integration can be regarded as a kind of process specification for how software will be developed; this specification can define a view of the process from many perspectives, spanning individual roles through larger organizational pespectives. In the case of CM, process integration refers to policies and procedures for carrying out CM activities.

Integration occurs within each of these levels of integration; thus, mechanisms are inte- 34 ATR grated with mechanisms, services with services, and process elements with process elements. There are also relationships that span the levels. The relationship between the mechanism level and the services level is an implementation relationship: a CM concept in  he services layer may be implemented by different tools in the mechanism level, and conversely, a single mechanism may implement more than one CM concept. The relationship between the services level and the process level is a process adaptation relationship: different CM services may be combined, and tuned, to support different process requirements.

image

This three-level model provides a working context for understanding integration. For the moment, however, existing integration technology does not match exactly this somewhat idealized model of integration. For example, many services provided by CASE tools (including CM) embed process constraints that should logically be separate, i.e., reside in the process level. Similarly, tool services are often closely coupled to particular implementation techniques.

The level of adaptability required of integrating CM—both in terms of adaptability for projectspecific requirements as well as adaptability to multiple underlying CM
implementations—pushes the limits of available environment integration techniques. The following sections describe the current state of integration technology and its limitations. The next chapter discusses how future generation integration technology can address these shortcomings.

Reference: 
The State of Automated Configuration Management.
A. Brown, S. Dart, P. Feiler, K. Wallnau

Tagged : / / / / / / / / / /