0% found this document useful (0 votes)
75 views

Introduction To Databases

The document provides an introduction to databases and database management systems. It discusses what a database is, examples of common databases, and how a database management system acts as an interface between users and the database. It then discusses relational database management systems and their key aspects, including Codd's 12 rules for RDBMS. It provides an example of Oracle's logical and physical database structures and components. Finally, it discusses data types and guidelines for designing tables in a database.

Uploaded by

Kundan Solanki
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
75 views

Introduction To Databases

The document provides an introduction to databases and database management systems. It discusses what a database is, examples of common databases, and how a database management system acts as an interface between users and the database. It then discusses relational database management systems and their key aspects, including Codd's 12 rules for RDBMS. It provides an example of Oracle's logical and physical database structures and components. Finally, it discusses data types and guidelines for designing tables in a database.

Uploaded by

Kundan Solanki
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Introduction to Databases.

DATABASE

A database is a collection of Data (Information).  Examples of databases, which we use in our


daily life, is  an Attendance Register, Telephone Directory, Muster Rule.

Database Management System(DBMS): A database management system is a collection of


programs written to manage a database. That is, it acts as a interface between user and database.

RDBMS

A Database Management System based on Relational Data Model is known as Relational


Database Management System (RDBMS).

The father of Relational Data Model was Dr. E.F. CODD. He developed the relational data
model by taking the concept from Relational Algebra in  June-1970.

Relational Data Model is nothing but 12 Rules which are named after Codd as Codd Rules.
According to Codd a package can be called as RDBMS only if it satisfies the Codd Rules.

ORACLE

Oracle is an Object-Relational Database Management System. It is the leading RDBMS vendor


worldwide. Nearly half of RDBMS  worldwide market is owned by Oracle. 
ORACLE DATABASE

Every Oracle Database Contains Logical and Physical Structures. Logical Structures are
tablespaces, Schema objects, extents and segments. Physical Structures are Datafiles, Redo Log
Files, Control File.

A database is divided into logical storage units called tablespaces, which group related logical
structures together. Each Tablespace in turn consists of one are more datafiles.

All the tables and other objects are stored in tablespace logically, but physically they are stored
in the datafiles associated with the tablespace.

Every Oracle database has a set of two or more redo log files. The set of redo log files for a
database is collectively known as the database's redo log. A redo log is made up of redo entries
(also called redo records).

The primary function of the redo log is to record all changes made to data. If a failure prevents
modified data from being permanently written to the datafiles, the changes can be obtained from
the redo log so work is never lost.

Every Oracle database has a control file. A control file contains the database name and locations
of all datafiles and redo log files.

Every Oracle database also has a Parameter File. Parameter file contains the name of the
Database, Memory Settings and Location of Control file.

CODD’S RULES
1                    Information Rule: All information in a relational database including table names,
column names are represented by values in tables. This simple view of data speeds
design and learning. User productivity is improved since knowledge of only one language
is necessary to access all data such as description of the table and attribute definitions,
integrity constraints. Action can be taken when the constraints are violated. Access to
data can be restricted. All these information are also stored in tables.

2                    Guaranteed Access Rule: Every piece of data in a relational database, can be
accessed by using combination of a table name, a primary key value that identifies the
row and column name which identified a cell. User productivity is improved since there
is no need to resort to using physical pointers addresses. Provides data independence.
Possible to retrieve each individual piece of data stored in a relational database by
specifying the name of the table in which it is stored, the column and primary key which
identified the cell in which it is stored.

3                    Systematic Treatment of Nulls Rule: The RDBMS handles records that have unknown
or inapplicable values in a pre-defined fashion. Also, the RDBMS distinguishes between
zeros, blanks and nulls in the records hand handles such values in a consistent manner
that produces correct answers, comparisons and calculations. Through the set of rules for
handling nulls, users can distinguish results of the queries that involve nulls, zeros and
blanks. Even though the rule doesn’t specify what should be done in the case of nulls it
specifies that there should be a consistent policy in the treatment of nulls.

4                    Active On-line catalog based on the relational model: The description of a database
and in its contents are database tables and therefore can be queried on-line via the data
manipulation language. The database administrator’s productivity is improved since the
changes and additions to the catalog can be done with the same commands that are used
to access any other table. All queries and reports can also be done as any other table.

5                    Comprehensive Data Sub-language Rule: A RDBMS may support several languages.
But at least one of them should allow user to do all of the following: define tables and
views, query and update the data, set integrity constraints, set authorizations and define
transactions. User productivity is improved since there is just one approach that can be
used for all database operations. In a multi-user environment the user does not have to
worry about the data integrity an such things, which will be taken care by the system.
Also, only users with proper authorization will be able to access data.

6                    View Updating Rule: Any view that is theoretically updateable can be updated using
the RDBMS. Data consistency is ensured since the changes made in the view are
transmitted to the base table and vice-versa.

7                    High-Level Insert, Update and Delete: The RDBMS supports insertions, updation and
deletion at a table level. The performance is improved since the commands act on a set of
records rather than one record at a time.

8                    Physical Data Independence: The execution of adhoc requests and application
programs is not affected by changes in the physical data access and storage methods.
Database  administrators can make changes to the physical access and storage method
which improve performance and do not require changes in the application programs or
requests. Here the user specified what he wants an need not worry about how the data is
obtained.

9                    Logical Data Independence: Logical changes in tables and views such adding/deleting
columns or changing fields lengths need not necessitate modifications in the programs or
in the format of adhoc requests. The database can change and grow to reflect changes in
reality without requiring the user intervention or changes in the applications. For
example, adding attribute or column to the base table should not disrupt the programs or
the interactive command that have no use for the new attribute.

10                Integrity Independence: Like table/view definition, integrity constraints are stored in
the on-line catalog and can therefore be changed without necessitating changes in the
application programs. Integrity constraints specific to a particular RDB must be
definable in the relational data sub-language and storable in the catalog. At least the
Entity integrity and referential integrity must be supported.

11                Distribution Independence: Application programs and adhoc requests are not affected
by change in the distribution of physical data. Improved systems  reliability since
application programs will work even if the programs and data are moved in different
sites.

12                No subversion Rule: If the RDBMS has a language that accesses the information of a
record at a time, this language should not be used to bypass the integrity constraints.
This is necessary for data integrity.

According to Dr. Edgar. F. Codd, a relational database management system must be able to
manage the database entirely through its relational capabilities.

Oracle Datatypes and Creating Tables Example

Datatypes and Creating Tables

A table is the data structure that holds data in a relational database. A table is composed of rows
and columns.
A table in Oracle Ver. 7.3 can have maximum 255 Columns and in Oracle Ver. 8 and above a
table can have maximum 1000 columns. Number of rows in a table is unlimited in all the
versions.

A table can represent a single entity that you want to track within your system. This type of a
table could represent a list of the employees within your organization, or the orders placed for
your company's products.

A table can also represent a relationship between two entities. This type of a table could portray
the association between employees and their job skills, or the relationship of products to orders.
Within the tables, foreign keys are used to represent relationships.

Although some well designed tables could represent both an entity and describe the relationship
between that entity and another entity, most tables should represent either an entity or a
relationship.

The following sessions explain how to create, alter, and drop tables. Some simple guidelines to
follow when managing tables in your database are included.

Designing Tables

Consider the following guidelines when designing your tables:

Use descriptive names for tables, columns, indexes, and clusters.

Be consistent in abbreviations and in the use of singular and plural forms of table names and
columns.
Document the meaning of each table and its columns with the COMMENT command.

Normalize each table.


Select the appropriate datatype for each column.

Define columns that allow nulls last, to conserve storage space.

Cluster tables whenever appropriate, to conserve storage space and optimize performance of SQL
statements.

Before creating a table, you should also determine whether to use integrity constraints. Integrity
constraints can be defined on the columns of a table to enforce the business rules of your
database automatically.

Before creating a Table you have to decide what type of data each column can contain. This is
known as datatype.  Lets Discuss what datatypes are available in Oracle.

Datatypes

A datatype associates a fixed set of properties with the values that can be used in a column of a
table or in an argument of a procedure or function. These properties cause Oracle to treat values
of one datatype differently from values of another datatype. For example, Oracle can add values
of NUMBER datatype, but not values of RAW datatype.

Oracle supplies the following built-in datatypes:

Character datatypes
oCHAR
oNCHAR
oVARCHAR2 and VARCHAR
oNVARCHAR2
oCLOB
oNCLOB
oLONG

NUMBER datatype

Time and date datatypes:


oDATE
oINTERVAL DAY TO SECOND
oINTERVAL YEAR TO MONTH
oTIMESTAMP
oTIMESTAMP WITH TIME ZONE
oTIMESTAMP WITH LOCAL TIME ZONE

Binary datatypes
oBLOB
oBFILE
oRAW
oLONG RAW

Another datatype, ROWID, is used for values in the ROWID pseudocolumn, which represents the
unique address of each row in a table.

The following table summarizes the information about each Oracle built-in datatype.

Datatype  Description  Column Length and Default  


CHAR (size Fixed-length character data of Fixed for every row in the table (with trailing
[BYTE | CHAR])  length size bytes or characters.  blanks); maximum size is 2000 bytes per row,
default size is 1 byte per row. Consider the
character set (single-byte or multibyte) before
setting size. 
VARCHAR2 Variable-length character data, Variable for each row, up to 4000 bytes per row.
(size [BYTE | with maximum length size bytes or Consider the character set (single-byte or
CHAR])  characters.  multibyte) before setting size. A maximum size
must be specified. 
NCHAR (size)  Fixed-length Unicode character Fixed for every row in the table (with trailing
data of length size characters.  blanks). Column size is the number of characters.
(The number of bytes is 2 times this number for
the AL16UTF16 encoding and 3 times this
number for the UTF8 encoding.) The upper limit is
2000 bytes per row. Default is 1 character.  
NVARCHAR2 Variable-length Unicode character Variable for each row. Column size is the number
(size)  data of length size characters. A of characters. (The number of bytes may be up to 2
maximum size must be specified.  times this number for a the AL16UTF16 encoding
and 3 times this number for the UTF8 encoding.)
The upper limit is 4000 bytes per row. Default is 1
character.  
CLOB   Single-byte character data  Up to 232 - 1 bytes, or 4 gigabytes. 
NCLOB   Unicode national character set Up to 232 - 1 bytes, or 4 gigabytes.  
(NCHAR) data. 
LONG  Variable-length character data.  Variable for each row in the table, up to 232 - 1
bytes, or 2 gigabytes, per row. Provided for
backward compatibility.  
NUMBER (p, s) Variable-length numeric data. Variable for each row. The maximum space
Maximum precision p and/or scale required for a given column is 21 bytes per row. 
s is 38. 
DATE  Fixed-length date and time data, Fixed at 7 bytes for each row in the table. Default
ranging from Jan. 1, 4712 B.C.E. format is a string (such as DD-MON-RR) specified
to Dec. 31, 4712 C.E.  by the NLS_DATE_FORMAT parameter.  
INTERVAL YEAR A period of time, represented as Fixed at 5 bytes. 
(precision) TO years and months. The precision
MONTH  value specifies the number of
digits in the YEAR field of the
date. The precision can be from 0
to 9, and defaults to 2 for years. 
INTERVAL DAY A period of time, represented as Fixed at 11 bytes. 
(precision) TO days, hours, minutes, and seconds.
SECOND
(precision) The precision values specify the
number of digits in the DAY and
  the fractional SECOND fields of
the date. The precision can be from
0 to 9, and defaults to 2 for days
and 6 for seconds. 
TIMESTAMP A value representing a date and Varies from 7 to 11 bytes, depending on the
(precision)  time, including fractional seconds. precision. The default is determined by the
(The exact resolution depends on NLS_TIMESTAMP_FORMAT initialization
the operating system clock.) parameter. 

The precision value specifies the


number of digits in the fractional
second part of the SECOND date
field. The precision can be from 0
to 9, and defaults to 6 
TIMESTAMP A value representing a date and Fixed at 13 bytes. The default is determined by the
(precision) time, plus an associated time zone NLS_TIMESTAMP_TZ_FORMAT initialization
WITH TIME setting. The time zone can be an parameter. 
ZONE  offset from UTC, such as '-
5:0', or a region name, such as  
'US/Pacific'. 
 
TIMESTAMP Similar to TIMESTAMP WITH Varies from 7 to 11 bytes, depending on the
(precision) TIME ZONE, except that the data precision. The default is determined by the
WITH LOCAL is normalized to the database time NLS_TIMESTAMP_FORMAT initialization
TIME ZONE  zone when stored, and adjusted to parameter. 
match the client's time zone when
retrieved. 
BLOB   Unstructured binary data   Up to 232 - 1 bytes, or 4 gigabytes. 
BFILE   Binary data stored in an external Up to 232 - 1 bytes, or 4 gigabytes. 
file  
RAW (size)  Variable-length raw binary data   Variable for each row in the table, up to 2000
bytes per row. A maximum size must be specified.
Provided for backward compatibility.  
LONG RAW  Variable-length raw binary data  Variable for each row in the table, up to 231 - 1
  bytes, or 2 gigabytes, per row. Provided for
  backward compatibility.  
 
ROWID  Binary data representing row Fixed at 10 bytes (extended ROWID) or 6 bytes
addresses  (restricted ROWID) for each row in the table.  

Representing Character Data

Use the character datatypes to store alphanumeric data:

CHAR and NCHAR datatypes store fixed-length character strings.

VARCHAR2 and NVARCHAR2 datatypes store variable-length character strings. (The VARCHAR
datatype is synonymous with the VARCHAR2 datatype.)
NCHAR and NVARCHAR2 datatypes store Unicode character data only.
CLOB and NCLOB datatypes store single-byte and multibyte character strings of up to four
gigabytes.
The LONG datatype stores variable-length character strings containing up to two gigabytes, but with
many restrictions.

This datatype is provided for backward compatibility with existing applications; in general,
new applications should use CLOB and NCLOB datatypes to store large amounts of character
data, and BLOB and BFILE to store large amounts of binary data.

When deciding which datatype to use for a column that will store alphanumeric data in a table,
consider the following points of distinction:

To store data more efficiently, use the VARCHAR2 datatype. The CHAR datatype blank-pads and
stores trailing blanks up to a fixed column length for all column values, while the VARCHAR2
datatype does not add any extra blanks.
For example if you define  empname as char(20) then if you store names like “Sami” then name will
occupy 20 bytes( 4 bytes for characters “Sami” and 16 blank spaces)
And if you define  empname as varchar2(20) then if you store names like “Sami” then oracle will take 4
bytes only.
Use the CHAR datatype when you require ANSI compatibility in comparison semantics (when
trailing blanks are not important in string comparisons). Use the VARCHAR2 when trailing blanks are
important in string comparisons.
The CHAR and VARCHAR2 datatypes are and will always be fully supported. At this time, the
VARCHAR datatype automatically corresponds to the VARCHAR2 datatype and is reserved for future
use.

Representing Numeric Data

Use the NUMBER datatype to store real numbers in a fixed-point or floating-point format. Numbers
using this datatype are guaranteed to be portable among different Oracle platforms, and offer up
to 38 decimal digits of precision. You can store positive and negative numbers of magnitude
1 x 10-130 through 9.99 x10125, as well as zero, in a NUMBER column.

You can specify that a column contains a floating-point number, for example:

distance NUMBER

Or, you can specify a precision (total number of digits) and scale (number of digits to right of
decimal point):
price NUMBER (8, 2)

Although not required, specifying precision and scale helps to identify bad input values. If a
precision is not specified, the column stores values as given. The following table shows
examples of how data different scale factors affect storage.

Input Data  Specified As  Stored As 


4,751,132.79   NUMBER  4751132.79 
4,751,132.79   NUMBER (9)  4751133
4,751,132.79   NUMBER (9,2)  4751132.79 
4,751,132.79  NUMBER (9,1)  4751132.7 
4,751,132.79  NUMBER (6)  (not accepted, exceeds precision) 
4,751,132.79  NUMBER (7, -2)  4,751100 

Representing Date and Time Data

Use the DATE datatype to store point-in-time values (dates and times) in a table. The DATE
datatype stores the century, year, month, day, hours, minutes, and seconds.

Use the TIMESTAMP datatype to store precise values, down to fractional seconds. For example, an
application that must decide which of two events occurred first might use TIMESTAMP. An
application that needs to specify the time for a job to execute might use DATE.

Date Format

For input and output of dates, the standard Oracle default date format is DD-MON-RR. For
example:

'13-NOV-1992'

To change this default date format on an instance-wide basis, use the NLS_DATE_FORMAT
parameter. To change the format during a session, use the ALTER SESSION statement. To enter
dates that are not in the current default date format, use the TO_DATE function with a format
mask. For example:

TO_DATE ('November 13, 1992', 'MONTH DD, YYYY')

Be careful using a date format like DD-MON-YY. The YY indicates the year in the current century.
For example, 31-DEC-92 is December 31, 2092, not 1992 as you might expect. If you want to
indicate years in any century other than the current one, use a different format mask, such as the
default RR.

Time Format

Time is stored in 24-hour format, HH24:MI:SS. By default, the time in a date field is 12:00:00
A.M. (midnight) if no time portion is entered. In a time-only entry, the date portion defaults to
the first day of the current month. To enter the time portion of a date, use the TO_DATE function
with a format mask indicating the time portion, as in:

INSERT INTO Birthdays_tab (bname, bday) VALUES

    ('ANNIE',TO_DATE('13-NOV-92 10:56 A.M.','DD-MON-YY HH:MI


A.M.'));

Creating Tables in Oracle

Once you have designed the table and decided about datatypes use the following SQL command
to create a table.

For example, the following statement creates a table named Emp.

CREATE TABLE Emp (


   Empno      NUMBER(5),
   Ename      VARCHAR2(15),
   Hiredate   DATE,
   Sal        NUMBER(7,2)
                      );

To insert rows in the table you can use SQL  INSERT command.

For example the following statement creates a row in the above table.

SQL>insert into emp values (101,’Sami’,3400);

To insert rows continuously in SQL Plus you can give the following command.

SQL>insert into emp values (&empno,’&name’,&sal);

These &Empno, &name and &sal  are known as substitution variables. That is SQLPlus will prompt you
for these values and then rewrites the statement with supplied values.

To see the rows you have inserted give the following command.

SQL> Select * from emp; 

To see the structure of the table i.e. column names and their datatypes and widths. Give the following
command.

SQL>desc  emp
To see how many tables are in your schema give the following command.

SQL> select * from cat;

or

SQL>select * from tab;

You might also like