Monday, February 24, 2014

ORACLE KEY'S + NORMALIZATION + ORACLE DATATYPES

HOW MANY TYPE OF KEYS WE ARE USING IN ORACLE DATABASE? WHAT ARE THOSE? EXPLAIN IT?

PRIMARY KEY (SUPER KEY) 
This key uniquely define a column value. Here we never insert NULL values.

CREATE TABLE TEMP_PRIMARY
(
   COL1 VARCHAR2(10),
   COL2 VARCHAR2(10),
   COL3 VARCHAR2(10),
   CO4L_DATE DATE,
   CONSTRAINT CON_PK_COL1 PRIMARY KEY (COL1)
);

We can also alter,drop, enable/disable the constraints
ALTER TABLE TEMP_PRIMARY ADD CONSTRAINT CON_NOTNULL_COL4 NOT NULL(COL4);
ALTER TABLE TEMP_PRIMARY DROP CONSTRAINT CON_NOTNULL_COL4;
ALTER TABLE TEMP_PRIMARY ENABLE/DISABLE CONSTRAINT CON_NOTNULL_COL4;



FOREIGN KEY (REFERENTIAL INTEGRITY)
This key is a referential integrity of primary key i.e. a primary key of table1 is a foreign key of table2 i.e. value of table1 must be present in table2
The table which has a primary key called as PARENT TABLE. The table which has the foreign keys are called as CHILD TABLE

CREATE TABLE TEMP_FOREIGN
(
   COL2 VARCHAR2(10),
   COL1 VARCHAR2(10),
   COL3 VARCHAR2(10),
   CO4L_DATE DATE,
   CONSTRAINT CON_PK_COL2 PRIMARY KEY (COL2),
   CONSTRAINT CON_FK_COL1 FOREIGN KEY(COL1) REFERENCES 

   TEMP_PRIMARY(COL1)
);

We can also alter,drop, enable/disable the constraints
ALTER TABLE TEMP_FOREIGN ADD CONSTRAINT CON_FK_COL1 FOREIGN KEY(COL1) REFERENCES TEMP_PRIMARY(COL1);
ALTER TABLE TEMP_PRIMARY DROP CONSTRAINT
CON_FK_COL1;
ALTER TABLE TEMP_PRIMARY ENABLE/DISABLE CONSTRAINT
CON_FK_COL1;


UNIQUE KEY (SECONDARY KEY)

This key can be use if you want a unique record on a column included null or we can say if you want to insert a unique value in a column of a table included null. Unique key can store null.

CREATE TABLE TEMP_FOREIGN
(
   COL2 VARCHAR2(10),
   COL1 VARCHAR2(10),
   COL3 VARCHAR2(10),
   CO4L_DATE DATE,
   CONSTRAINT CON_PK_COL2 PRIMARY KEY (COL2),
   CONSTRAINT CON_FK_COL1 FOREIGN KEY(COL1) REFERENCES

   TEMP_PRIMARY(COL1),
   CONSTRAINT CON_UK_COL3 UNIQUE (COL3)
);

We can also alter,drop, enable/disable the constraints
ALTER TABLE TEMP_FOREIGN ADD CONSTRAINT CON_UK_COL3 UNIQUE(COL3);
ALTER TABLE TEMP_
FOREIGN DROP CONSTRAINT CON_UK_COL3;
ALTER TABLE TEMP_
FOREIGN ENABLE/DISABLE CONSTRAINT CON_UK_COL3;


CANDIDATE (ALTERNATE KEY)
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.
All candidate keys which are not chosen as "Primary key" are Alternate keys.


COMPOSITE KEY (COMPOUND KEY/ AGGREGATE KEY/ CONCATENATED KEY)

A Composite Key is a Primary Key that consists on more than one column. We can put more than one Primary key on a table but that Primary Keys will be known as Composite Keys OR Composite Primary Key. Composite keys are also known as Compound, Concatenated or Aggregate keys

CREATE TABLE TEMP_PRIMARY
(
   COL1 VARCHAR2(10),
   COL2 VARCHAR2(10),
   COL3 VARCHAR2(10),
   CO4L_DATE DATE,
   CONSTRAINT CON_CK_COL123 PRIMARY KEY (COL1, COL2, COL3)
);

We can also alter,drop, enable/disable the constraints
ALTER TABLE TEMP_PRIMARY ADD CONSTRAINT CON_CK_COL123 PRIMARY KEY(COL1, COL2, COL3);
ALTER TABLE TEMP_PRIMARY DROP CONSTRAINT
CON_CK_COL123;
ALTER TABLE TEMP_PRIMARY ENABLE/DISABLE CONSTRAINT
CON_CK_COL123;








WHAT IS NORMALIZATION. WHY DO WE USE NOMALIZATION. WHEN DO WE USE NORMALIZATION ?
Normalization is a best method to create a database without having any DATA REDUNDANCY (Data that has same information but store in multiple place), EDGER CODD has introduced Three Forms of Normalization I.E. 1st, 2nd & 3rd Normal forms. Later BOYCE has developed BOYCE-CODE normal forms (BCNF)

Below I am trying to explain that Why do we use Normalization with it's rules

























Here the column values are REPEATING & the column BEST_FRIEND is NOT ATOMIC or SCALAR i.e this column is holding multiple values, So it simply called this table is not in Normalized form.


1NF Rules Says
• Each table cell should contain an atomic or a scalar or a single value  (NO DUPLICATE VALUES)
• Each record needs to be unique (HAVING PRIMARY KEY ATTRIBUTE)























Now every column has scalar value but again this is not in normalized form, Why? Because we have multiple columns with same kind of values i.e. BEST_FRIEND1,2,3,4,5 columns


2NF Rules Says
• Be in 1NF
• All the data's are divided into necessary tables (CUSTOMER DETAILS TABLE,ORDER DETAILS TABLE, SALES DETAILS TABLE ETC)
• Every non-key column must dependent on the entire primary key i.e. columns should use the Referential Integrity if a non-key column is holding the exact data
   from different table's column (HAVING FOREIGN KEY ATTRIBUTE)





















 




























These are the 1st & 2nd Normal forms. Now take an example to illustrate the 3NF


3NF Rules Says
• Be in 2NF
• Has no transitive functional dependencies (If we change a  value in one column, we have to change value on another column too)

























Here we can see the BEST_FRIEND_ADDRESS column data is transitive dependent on the BEST_FRIEND_ID column data I.E. If we will change the data in BEST_FRIEND_ID then we will have to change the data in BEST_FRIEND_ADDRESS column too. So for reducing REDUNDANCY + TRANSITIVE DEPENDENCY of BEST_FRIEND_ADDRESS column we should remove the column from this table and merge the column with BEST_FRIEND_INFO table


























This is 3NF
  
BCNF Rules
BCNF was developed by Raymond Boyce and E.F. Codd (later is widely considered the father of relational database design)

BCNF is an extension of 3rd Normal Form (3NF), for this reason it is frequently termed as 3.5NF.
3NF states that all data in a table must depend only on that table’s primary key, and not on any other field in the table. BCNF and 3NF are same but in some rare cases it does happen that a 3NF table is not BCNF. This may happen in tables with two or more overlapping composite candidate keys.







WHAT ARE ORACLE DATA-TYPES? KINDLY EXPLAIN?
8 Bits= 1 Byte
1 Megabyte= 1024 Bytes
1 Gigabyte= 1024 Megabyte
1 Terabyte= 1024 Gigabyte

Whenever you create a table, you must specify the datatypes of the columns. Datatypes are defining the range of a column. Constants are also associated with some datatypes. Below are the datatypes


CHAR: FIXED-LENGTH CHARACTER STRING (Minimum 1, Maximum 2000 Bytes),
NCHAR: UNICODE FIXED-LENGTH CHARACTER STRING (Minimum 1, Maximum 2000 Bytes),

CHAR datatype stores fixed-length characters in string. Oracle guarantee that  if a column has a 60 length of CHAR datatype then it must take character string up to the 60limits. If you have 40limits character then it is padded a blank space on the remaining 20limits. This is not very useful in use because it is taking the fixed storage.
NCHAR datatype stores unicode character data. It can only be either AL16UTF16 or UTF8
NOTE: Instead of taking CHAR or NCHAR, we should take VARCHAR2 or NVARCHAR2 because it is taking the storage as per the number of limits inserted into the database 


VARCHAR2 & VARCHAR: VARIABLE-LENGTH CHARACTER STRING (Minimum 1 , Maximum 4000 Bytes)
NVARCHAR2: UNICODE VARIDABLE-LENGTH CHARACTER STRING (Minimum 1 , Maximum 4000 Bytes)

VARCHAR2 datatype stores variable-length character string. Here can insert numeric values too. Oracle guarantee that if a column has 60 length of varchar2 datatype then it must take the variable length character string up to 60limits.If you have 40limits then it will take only 40limits not the complete 60limits.
This is the benefit of using Varchar2 datatype.
NVARCHAR2 datatype stores unicode variable-length character string. It can only be either AL16UTF16 or UTF8.


NUMBER[P,S]: PRECISION P AND SCALE S (Precision Range 1 TO 38, Scale range from -84 TO 127)
The NUMBER datatype stores fixed & floating-point numbers.


DATE: DATE AND TIME VALUES IN BETWEEN JAN 1, 4712B.C., AND DEC 31, 9999A.D.The data datatype stores YYYY-MON-DD HH:MI:SS AM/PM i.e. YEAR, MONTH, DATE, HOUR, MINUTE, SECOND & AM/PM


LOB: LARGE OBJECT
The LOB datatypes like BLOB, CLOB, NCLOB & BFILE enable you to store and manipulate the large blocks of unstructured data like text, graphic images, video clips and sound waveforms in binary or character format. Oracle recommends that you always use LOB datatypes over LONG datatypes. LOB datatypes differ from LONG and LONG RAW datatypes in several ways.
For example:
1. A table can contain multiple LOB columns but a table containing only one LONG column.
2. A table containing one or more LOB columns can be partitioned, but a table containing a LONG column cannot be partitioned.
3. The maximum size of a LOB is 128 terabytes depending on database block size, but the maximum size of a LONG is only 2 gigabytes.
4. LOB datatypes (except NCLOB) can be attributes of a user-defined object type but LONG datatypes cannot.
5. Temporary LOBs that act like local variables can be used to perform transformations on LOB data.
6. Temporary internal LOBs (BLOBs, CLOBs, and NCLOBs) are created in a temporary tablespace and are independent of tables. For LONG datatypes, however,
    no temporary structures are available.
7. Tables with LOB columns can be replicated, but tables with LONG columns cannot.

BLOB: BINARY LARGE OBJECT  (Minimum 1 , Maximum 128 terabytes)
The BLOB datatype stores unstructured binary data in the database. BLOBs can store up to 128 terabytes of binary data. BLOB locators cannot span(extend) transactions or sessions.
  
CLOB: CHARACTER LARGE OBJECT (Minimum 1 , Maxmimum 128 Terabytes)NCLOB: UNICODE CHARACTER LARGE OBJECT (Minimum 1 , Maxmimum 128 Terabytes)
The CLOB and NCLOB datatypes store up to 128 terabytes of character data in the database. CLOBs store database character set data, and NCLOBs store Unicode national character set data. CLOB and NCLOB locators cannot span transactions or sessions. You cannot create an object type with NCLOB attributes, but you can specify NCLOB parameters in a method for an object type.

BFILE: BINARY FILE (LIMIT DEPENDS ON THE OPERATING SYSTEM LIMIT)
The BFILE datatype stores unstructured binary data in operating-system files outside the database. A BFILE column or attribute stores a file locator that points to an external file containing the data. The amount of BFILE data that can be stored is limited by the operating system. BFILEs are read only, you cannot modify them. They support only random (not sequential) reads, and they do not participate in transactions. The underlying operating system must maintain the file integrity, security, and durability for BFILEs. The database administrator must ensure that the file exists and that Oracle Database processes have operating-system read permissions on the file


RAW & LONG RAW
The RAW and LONG RAW datatypes are used for data that is not to be interpreted (not converted when moving data between different systems) by Oracle Database. These datatypes are intended for binary data or byte strings. For example, LONG RAW can be used to store graphics, sound, documents, or arrays of binary data. The interpretation depends on the use.
RAW is a variable-length datatype like the VARCHAR2 character datatype, except Oracle Net Services (which connects user sessions to the instance) and the Import and Export utilities do not perform character conversion when transmitting RAW or LONG RAW data. In contrast, Oracle Net Services and Import/Export automatically convert CHAR, VARCHAR2, and LONG data between the database character set and the user session character set, if the two character sets are different.
When Oracle Database automatically converts RAW or LONG RAW data to and from CHAR data, the binary data is represented in hexadecimal form with one hexadecimal character representing every four bits of RAW data. For example, one byte of RAW data with bits 11001011 is displayed and entered as 'CB'.
LONG RAW data cannot be indexed, but RAW data can be indexed.

NOTE: The LONG RAW datatype is provided for backward compatibility with existing applications. For new applications, use the BLOB and BFILE datatypes for large amounts of binary data. Oracle also recommends that you convert existing LONG RAW columns to LOB columns. LOB columns are subject to far fewer restrictions than LONG columns. Further, LOB functionality is enhanced in every release, whereas LONG RAW functionality has been static for several releases.


ROW ID
Oracle Database uses a ROWID datatype to store the address (rowid) of every row in the database.
  • Physical rowids store the addresses of rows in ordinary tables (excluding index-organized tables), clustered tables, table partitions and subpartitions, indexes, and index partitions and subpartitions.
  • Logical rowids store the addresses of rows in index-organized tables.
A single datatype called the universal rowid, or UROWID, supports both logical and physical rowids, as well as rowids of foreign tables such as non-Oracle tables accessed through a gateway.






NOTE: IF YOU HAVE DOUBTS, KINDLY CONTACT ME VIA THIS BLOG

No comments:

Post a Comment