Showing posts with label database concepts. Show all posts
Showing posts with label database concepts. Show all posts

Friday, June 4, 2010

DDL, DML & DCL

What are the difference between DDL,  DML and DCL commands?

DDL

Data Definition Language (DDL) statements are used to define the database structure or schema. Some examples:
  • CREATE - to create objects in the database
  • ALTER - alters the structure of the database
  • DROP - delete objects from the database
  • TRUNCATE - remove all records from a table, including all spaces allocated for the records are removed
  • COMMENT - add comments to the data dictionary
  • RENAME - rename an object

DML

Data Manipulation Language (DML) statements are used for managing data within schema objects. Some examples:
  • SELECT - retrieve data from the a database
  • INSERT - insert data into a table
  • UPDATE - updates existing data within a table
  • DELETE - deletes all records from a table, the space for the records remain
  • MERGE - UPSERT operation (insert or update)
  • CALL - call a PL/SQL or Java subprogram
  • EXPLAIN PLAN - explain access path to data
  • LOCK TABLE - control concurrency

DCL

Data Control Language (DCL) statements. Some examples:
  • GRANT - gives user's access privileges to database
  • REVOKE - withdraw access privileges given with the GRANT command

TCL

Transaction Control (TCL) statements are used to manage the changes made by DML statements. It allows statements to be grouped together into logical transactions.
  • COMMIT - save work done
  • SAVEPOINT - identify a point in a transaction to which you can later roll back
  • ROLLBACK - restore database to original since the last COMMIT
  • SET TRANSACTION - Change transaction options like isolation level and what rollback segment to use

FOREIGN KEY

 A foreign key is a field (or fields) that points to the primary key of another table. The purpose of the foreign key is to ensure referential integrity of the data. In other words, only values that are supposed to appear in the database are permitted.

For example, say we have two tables, a CUSTOMER table that includes all customer data, and an ORDERS table that includes all customer orders. The constraint here is that all orders must be associated with a customer that is already in the CUSTOMER table. In this case, we will place a foreign key on the ORDERS table and have it relate to the primary key of the CUSTOMER table. This way, we can ensure that all orders in the ORDERS table are related to a customer in the CUSTOMER table. In other words, the ORDERS table cannot contain information on a customer that is not in the CUSTOMER table.
The structure of these two tables will be as follows:
Table CUSTOMER
column namecharacteristic
SIDPrimary Key
Last_Name 
First_Name 

Table ORDERS
column namecharacteristic
Order_IDPrimary Key
Order_Date 
Customer_SIDForeign Key
Amount 

In the above example, the Customer_SID column in the ORDERS table is a foreign key pointing to the SID column in the CUSTOMER table.

Below we show examples of how to specify the foreign key when creating the ORDERS table:

MySQL:
CREATE TABLE ORDERS
(Order_ID integer,
Order_Date date,
Customer_SID integer,
Amount double,
Primary Key (Order_ID),
Foreign Key (Customer_SID) references CUSTOMER(SID));

Oracle:
CREATE TABLE ORDERS
(Order_ID integer primary key,
Order_Date date,
Customer_SID integer references CUSTOMER(SID),
Amount double);

SQL Server:
CREATE TABLE ORDERS
(Order_ID integer primary key,
Order_Date datetime,
Customer_SID integer references CUSTOMER(SID),
Amount double);

Below are examples for specifying a foreign key by altering a table. This assumes that the ORDERS table has been created, and the foreign key has not yet been put in:

MySQL:
ALTER TABLE ORDERS
ADD FOREIGN KEY (customer_sid) REFERENCES CUSTOMER(SID);
Oracle:
ALTER TABLE ORDERS
ADD (CONSTRAINT fk_orders1) FOREIGN KEY (customer_sid) REFERENCES CUSTOMER(SID);
SQL Server:
ALTER TABLE ORDERS
ADD FOREIGN KEY (customer_sid) REFERENCES CUSTOMER(SID);

Tuesday, May 25, 2010

Codd's Rules for Relational Database Design

In 1985, database pioneer Dr. E.F. Codd laid out twelve rules of relational database design. These rules provide the theoretical (although sometimes not practical) underpinnings for modern database design. The rules may be summarized as follows:
  • All database management must take place using the relational database's innate functionality
  • All information in the database must be stored as values in a table
  • All database information must be accessible through the combination of a table name, primary key and column name.
  • The database must use NULL Values to indicate missing or unknown information
  • The database schema must be described using the relational database syntax
  • The database may support multiple languages, but it must support at least one language that provides full database functionality (e.g. SQL)
  • The system must be able to update all updatable views
  • The database must provide single-operation insert, update and delete functionality
  • Changes to the physical structure of the database must be transparent to applications and users.
  • Changes to the logical structure of the database must be transparent to applications and users.
  • The database must natively support integrity constraints.
  • Changes to the distribution of the database (centralized vs. distributed) must be transparent to applications and users.
  • Any languages supported by the database must not be able to subvert integrity controls.
source: about.com

CANDIDATE KEY, PRIMARY KEY, UNIQUE KEY, ALTERNATE KEY, COMPOSITE KEY

CANDIDATE KEY, PRIMARY KEY, UNIQUE KEY, ALTERNATE KEY, COMPOSITE KEY

How many times do we feel confused about these simple database concepts?
The answer is many a times, but I'm sure after reading this post you will never forget any of them.

PRIMARY KEY:-A primary key is a field that uniquely identifies each record in a table. As it uniquely identify each entity, it cannot contain null value and duplicate value.


CANDIDATE KEY:-A nominee's for primary key field are know as candidate key.


ALTERNATE KEY:-A candidate key that is not the primary key is called an Alternate key.


SUPER KEY :- If we add additional attributes to a primary key, the resulting combination would still uniquely identify an instance of the entity set. Such augmented keys are called superkey. A primary key is therefore a minimum superkey.


A candidate key is one that can identify each row of a table uniquely. Generally a candidate key becomes the primary key of the table. If the table has more than one candidate key, one of them will become the primary key, and the rest are called alternate keys.

A key formed by combining at least two or more columns is called composite key.





Difference..
Primary Key..
1.It will not accept null values.
2.There will be only one primary key in a table.
3.Clustered index is created in Primary key.
4.Primary key allows each row in a table to be uniquely identified and ensures that no duplicate rows exist.

Unique Key..
1.Null values are accepted.
2.More than one unique key will be there in a table.
3.Non-Clustered index is created in unique key.
4.Unique key constraint is used to prevent the duplication of key values within the rows of a table and allow null values.



Also, check out Free ISTQB Training Material here

www.testing4success.com - Application QA/Testing     Mobile App QA/Testing     Web Testing     Training
Iphone App QA  Android App QA  Web QA

Friday, April 30, 2010

DATABASE NORMALIZATION



Normalization is the process of efficiently organizing data in a database. There are two goals of the normalization process: eliminating redundant data (for example, storing the same data in more than one table) and ensuring data dependencies make sense (only storing related data in a table). Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored.


First Normal Form (1NF)


First normal form (1NF) sets the very basic rules for an organized database:
  • Eliminate duplicative columns from the same table.
  • Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key).
To remember the first law of normalization just remember PRIMARY KEY.



Second Normal Form (2NF)

Second normal form (2NF) further addresses the concept of removing duplicative data:
  • Meet all the requirements of the first normal form.
  • Remove subsets of data that apply to multiple rows of a table and place them in separate tables.
  • Create relationships between these new tables and their predecessors through the use of foreign keys.
To remember the first law of normalization just remember FOREIGN KEY.




Third Normal Form (3NF)

Third normal form (3NF) goes one large step further:
  • Meet all the requirements of the second normal form.
  • Remove columns that are not dependent upon the primary key.




Fourth Normal Form (4NF)

Finally, fourth normal form (4NF) has one additional requirement:
  • Meet all the requirements of the third normal form.
  • A relation is in 4NF if it has no multi-valued dependencies.
Remember, these normalization guidelines are cumulative. For a database to be in 2NF, it must first fulfill all the criteria of a 1NF database.


--source about.com