MAP

Showing posts with label sql. Show all posts
Showing posts with label sql. Show all posts

Database Management System - 1, MCA DBMS Material Overview


Characteristics of DBMS
  • Data Integrity
  • Security
  • Consistency
  • Roll-back
  • Data Independence
  • Back-up Procedures
  • Concurrency Control
  • Version Control

DBMS Model
  • Hierarchical Model
  • Network Model
  • Relational Model

Components of DBMS
  • Data
  • Users
    • Report Writing
    • Query Language
    • Spreadsheets
    • End-user Interfaces
  • Hardware
  • Software
    • Command
    • Editing
    • Queries
    • Reporting
    • Analysis

Types of DBMS
  • Operational Databases
  • Analytical Databases
  • Distributed Databases
  • Personal End User Databases
  • Multimedia Databases
  • Special Purpose Databases

Transaction Management
  • Concept of Transaction
  • Transaction Outcomes
  • Transaction Support
  • Properties of Transactions
    • Atomicity
    • Consistency
    • Independence
    • Durability

Primary, Foreign and Candidate Keys
      • Identify and define the primary key attributes for each entity
      • Validate primary keys and relationships
      • Migrate the primary keys to establish foreign keys
·                                                         Define Primary Key attributes
·                                                         Validate Keys and Relationships
·                                                         A foreign key
·                                                         Candidate key
            Uniqueness property – No two distinct tuple of R have the same value for K
            Irreducibility property – No proper subset of K has uniqueness property

Functions of a DBMS
  • Data Definition
  • Data Manipulation
  • Data Security & Integrity
  • Data Recovery & Concurrency
  • Data Dictionary Maintenance
  • Performance

Role of the Database Administrator
  • Defining the Schema
  • Liaising with Users
  • Defining Security & Integrity Checks
  • Defining Backup / Recovery Procedures
  • Monitoring Performance

Normalization
  • Basic Concepts
  • Functional Dependencies
  • Simple Data
    • S# - supplier identification number (this is the primary key)
    • Status – status code assigned to city
    • City – name of city where supplier is located
    • P# - part number of part supplied
    • Qty> - quantity of parts supplied to date
o   First Normal Form
      • Insert
      • Delete
      • Update
  • Second Normal Form
    • S# - city, status
    • City – status
    • (s#,p#) – qty

The Entity – Relationship Model
  • Entities
  • Attributes
  • Connectivity and Cardinality
    • One to one (1:1)
    • One to many (1:N)
    • Many to many (M:M)
o   ER Notation

DBMS Architecture
o   External – individual user view
o   Conceptual – community user view
o   Internal – physical or storage view

Advantages of DBMS
  • Reduction of redundancies
  • Shared Data
  • Integrity
  • Security
  • Conflict Resolution
  • Data Independence

Disadvantages of DBMS
  • Larger file size
  • Increased complexity
  • Greater impact of failure
  • More difficult recovery

Properties of  DBMS
  • There are no duplicate tuples
  • Tuples are unordered (top to bottom)
  • Attributes are unordered (left to right)
  • All Attribute values are atomic

Codd’s Twelve Rules
  • The information rule
  • Guaranteed access rule
  • Systematic treatment of null values
  • Dynamic online catalog based on the relational model
  • Comprehensive data sub language rule
    • Data definition
    • View definition
    • Data manipulation (interactive and by program)
    • Integrity constraints
    • Authorization
    • Transaction boundaries (begin, commit and rollback)
o   View updating rule
o   High – level insert, update and delete
o   Physical data independence
o   Logical data independence
o   Integrity independence
o   Distribution independence
o   Non subversion rule

DDL (Data Definition Language)
o   Create
o   Drop
o   Alter
o   Truncate
o   DBCC (Database Console Commands)

DML (Data Manipulation Language)
  • Data Manipulation is:
    • Retrieval of information from the database
    • Insertion of new information into the database
    • Deletion of information in the database
    • Modification of information in the database
  • A DML is a language which enables users to access and manipulate data
Two types of DML
o   Procedural
o   Nonprocedural
o   Easier for user
o   May not generate code as efficient as that produced by procedural languages

DCL (Data Control Language)
  • GRANT to allow specified users to perform specified tasks
  • REVOKE to cancel previously granted or denied permissions

  • CONNENCT allows a user to connect to the database or schema
  • SELECT allows a user to select records
  • INSERT allows a user to insert records
  • UPDATE allows a user to update records
  • DELETE allows a user to delete records
  • USAGE allows a user to use a database object such as a schema or a function

ACID (Atomicity, Consistency, Independence and Durability)

Datatypes Used in Oracle 9i



Datatypes Used in Oracle 9i


(Page 1 of 3 )

For those who use databases but are not familar to the Oracle 9i database, perhaps you should read about the datatypes used in Oracle 9i and how they can be used to support object orientation.
It is assumed that you have read my previous Oracle article based on creating an Oracle database in the latest Oracle database 9i. Before we can create a table, one should sit down and take the time to get to know the datatypes available for Oracle.
Also, upon reading articles relating to the Oracle database, you should have come across the term Abstract datatypes. This article will discuss abstract datatypes in depth so that creating a table, which is designed to include abstract datatypes, will inevitably become more understandable. These abstract datatypes, which I like to call user-defined types, are datatypes that behave like objects.
Oracle Datatypes
These Oracle datatypes are as follows:
Character Strings
  • CHAR (size) – A fixed-sized field of characters. The largest this particular datatype can become is 2000 bytes. In other words, it can only hold 2000 characters. If you don’t specify the length of the CHAR datatype, the default size is a single character (i.e. 1 byte).
  • NCHAR (size) – A fixed-sized field of characters, where the character set is determined by its definition. So, the maximum size is 2000 bytes per row or 2000 characters. This handles multibyte character sets.
  • VARCHAR2 (size) – A variable-sized field of characters. The largest this datatype can become is 4000 characters.
  • NVARCHAR2 (size) – A variable-sized field of characters, where the character set is determined by its definition. The maximum size is 4000 bytes per row or 4000 characters. This handles multibyte character sets.
Note: The VARCHAR2 datatype is the successor of VARCHAR. So it is recommended that you use VARCHAR2 as a variable-sized array of characters.
  • LONG – A variable-sized field of characters. The maximum size of this field is 2GB.
Number
  • NUMBER (precision, scale) – A variable-sized number, where the precision is between 1 and 38 and size is between -84 and 127. A NUMBER datatype with only one parameter is NUMBER (precision), where the parameter specifies the precision of the number. A NUMBER datatype with no parameters is set to its maximum size.
Date and Time
  • DATE – A fixed-sized 7 bit field that is used to store dates. One thing to note is that the time is stored as part of the date. The default format DD-MON-YY can be overridden by NLS_DATE_FORMAT.
  • TIMESTAMP (precision) – A variable-sized value ranging from 7 to 11 bytes, that is used to represent a date/time value. It includes both date and time. The precision parameter determines how many numbers are in the fractional part of SECOND field. The precision of the SECOND field within the TIMESTAMP value may have a value ranging from 0 to 9 with a default precision of 6.
  • TIMESTAMP (precision) WITH TIME ZONE – A fixed-sized value of 13 bytes, which represents a date/time value along with a time zone setting. There are two ways one can set the time zone. The first is by using the UTC offset, say ‘+10:0’, or secondly by the region name, say ‘Australia/Sydney’.
  • TIMESTAMP (precision) WITH LOCAL TIME – A variable value ranging from 7 to 11 bytes. This particular datatype is similar to the TIMESTAMP WITH TIME ZONE datatype. The difference is that the data is normalised to the database time zone when stored. The entry is manipulated to concur with the client’s time zone when retrieved.
Intervals
  • INTERVAL DAY (day_precision) TO SECOND (second_precision) – A fixed-sized 11 byte value that represents a period of time. It includes days, hours, minutes and seconds.
  • INTERVAL YEAR (year_precision) TO MONTH - A fixed-sized 5 byte value that represents a period of time. It includes years and months.
Binaries
  • RAW (size) – A variable-sized field of raw binary data. The maximum size for this datatype is 2000 bytes.
  • LONG RAW - A variable-sized field of raw binary data. The maximum size for this datatype is 2 GB.
  • BLOB – The Binary Large Object is a field that holds unstructured binary data. The maximum size for this datatype is 4 GB.
  • CLOB – The Character Large Object is a field that holds single byte character data. The maximum size for this datatype is 4 GB.
  • NCLOB – The National Character Large Object is a field that holds either single byte of multibyte character data dependent on the national character set. The maximum size for this datatype is 4 GB.
  • BFILE – An external binary file. The maximum size for this file is 4 GB. The size is also limited by the operating system.
Rows
  • ROWID – A datatype that contains binary data that is used to identify a row.
Each ROWID is:
    • 6 bytes for normal indexes on non-partitioned tables, local indexes on partitioned tables and row pointers for chained/migrated rows.
    • 10 bytes for global indexes on partitioned tables.
  • UROWID – The Universal ROWID is the datatype used to store both logical and physical ROWID values as well as foreign tables accessed through a gateway.
Alternatives for ANSI Standard Datatypes
Instead of using ANSI standard datatypes, you can use Oracle defined datatypes. View the table below to see the Oracle datatype alternative for ANSI standard datatypes.
ANSI Standard Oracle Datatype
CHARACTER and CHAR CHAR
CHARACTER VARYING and CHAR VARYING VARCHAR2
NUMERIC, DECIMAL, DEC, INTEGER, INT and SMALLINT NUMBER
FLOAT, REAL, DOUBLE PRECISION FLOAT
Abstract Datatypes
In Oracle, one may create there own datatypes. Abstract datatypes allow Oracle to hold a range of datatypes. So, an abstract datatypes can have many parts to it. To do this one needs to create the datatype as an object. This object is made up of one or more datatypes.
Example of an Abstract Datatype
Let’s say that we want a datatype to split up a person’s address. The abstract datatype may be,
CREATE OR REPLACE TYPE persons_address AS OBJECT
(
          v_streetNumber                      NUMBER,
          v_streetName                         VARCHAR2(30),
          v_citySuburb                          VARCHAR2(30),
          v_state                                  VARCHAR2(4),
          v_postCode                            NUMBER
);

When we create a table that references this abstract datatype the values must be inserted as
persons_address(21, ‘Kings Street’, ‘Junkville’, TN, 12345)
You should now know what datatypes exist in Oracle 9i. You should also understand how one could use this datatypes to create abstract datatypes and hence support object orientation.
Now you understand how datatypes work in Oracle, you should be ready to create Oracle tables.

Normalization in database management system - 1


Normalization
Ø  Normalization is a process of simplifying relationship between data elements in a record
Ø  With the help of normalization a record structure is replaced with a new record structure which is more simper and more manageable.
Ø  Normalization is performed for following reason
Ø  To provide structured data to represent relationship easily
Ø  To provide simple retrieval of data in response of query and
Ø  To simplify various operations like update, deletion, and insertions
Ø  To reduce the amount of restructure or reorganize activity when any changes occurs

Un-Normalized Data


PRODUCT REPORT

PROD.
NO.
PRODUCT
NAME
PROD.
COST
PART
NO.
PART
NAME
QTY.
USE
SUP
NO.
SUP
NAME
SUP
CITY
101
Generator
10000
201
WHEELS
4
301
STEELCO
BARODA
202
BOLTS
100
302
TISCO
TATANAGAR
203
STEEL BAR
10
301
STEELCO
BARODA
102
ENGINE
20000
202
BOLTS
200
302
TISCO
TATANAGAR
203
STEEL BAR
20
301
STEELCO
BARODA
204
PIPES
10
303
SAIL
INDORE

How to achieve First Normal Form?

Ø  Variable length of records creates no. of problems as system has to keep track of when record starts and when records ends. Thus we have to provide a table with fixed length records

PRODUCT REPORT

PROD.
NO.
PRODUCT
NAME
PROD.
COST
PART
NO.
PART
NAME
QTY.
USE
SUP
NO.
SUP
NAME
SUP
CITY
101
Generator
10000
201
WHEELS
4
301
STEELCO
BARODA
101
Generator
10000
202
BOLTS
100
302
TISCO
TATANAGAR
101
Generator
10000
203
STEEL BAR
10
301
STEELCO
BARODA
102
ENGINE
20000
202
BOLTS
200
302
TISCO
TATANAGAR
102
ENGINE
20000
203
STEEL BAR
20
301
STEELCO
BARODA
102
ENGINE
20000
204
PIPES
10
303
SAIL
INDORE

Ø  First normal form is achieved when all the repeating groups are removed so that a record can be of fixed length and creating a separate file or relation containing repeating group.
Ø  Here the original record and new records are interrelated by a common data item.
Ø  In this example we will remove repeating fields and will create a separate table.
Ø  Thus in Product table we keep PROD-NO, PRODUCT NAME and PROD.COST, while in PRODUCT_PART table we keep all the remaining columns with PROD_NO(key field) column to preserve relationship.



FIRST NORMAL FORM

PRODUCT

PROD.
NO.
PRODUCT
NAME
PROD.
COST
101
Generator
10000
102
ENGINE
20000

PRODUCT-PART

PROD.
NO.
PART
NO.
PART
NAME
QTY.
USE
SUP
NO.
SUP
NAME
SUP
CITY
101
201
WHEELS
4
301
STEELCO
BARODA
101
202
BOLTS
100
302
TISCO
TATANAGAR
101
203
STEEL BAR
10
301
STEELCO
BARODA
102
202
BOLTS
200
302
TISCO
TATANAGAR
102
203
STEEL BAR
20
301
STEELCO
BARODA
102
204
PIPES
10
303
SAIL
INDORE

Second Normal Form

Ø  Second normal form is achieved when a record is in first normal form and each item in the record is fully dependent on the primary record for identification
Ø  Second normal form applies Functional Dependency on record structure.

 

Functional Dependency

A data item is functionally dependent if its value is uniquely associated with a specific data item. Means each data item should be fully dependent of some key attribute for access.

Ø  To achieve second normal form every data item in a record that is not dependent on the primary key of the record should be removed and used to form a separate table or relation
Ø  In PRODUCT-PART table we are having composite primary key (PROD_ NO + PART_NO). Here field QTY_USE full dependent upon the primary key where as other fields are not fully dependent on this composite primary key thus we keep (PROD_ NO, PART_NO, QTY_USE) in PRODUCT_PART table.
Ø  Remaining columns (PARTNAME,SUP NO.,SUP NAME,SUP CITY) will be kept in other  new table that is PART table.
SECOND NORMAL FORM

PRODUCT

PROD.
NO.
PRODUCT
NAME
PROD.
COST
101
Generator
10000
102
ENGINE
20000

PRODUCT-PART

PROD.
NO.
PART
NO.
QTY.
USE
101
201
4
101
202
100
101
203
10
102
202
200
102
203
20
102
204
10

PART

PART
NO.
PART
NAME
SUP
NO.
SUP
NAME
SUP
CITY
201
WHEELS
301
STEELCO
BARODA
202
BOLTS
302
TISCO
TATANAGAR
203
STEEL BAR
301
STEELCO
BARODA
204
PIPES
303
SAIL
INDORE


Third Normal Form

Ø  Third normal form is achieved when transitive dependency are removed from a record design
Ø  Transitive Dependency Example
Ø  For example there are 3 data items in a record A,B,C
Ø  If C is functionally dependent on B
Ø  If B is functionally dependent on A
Ø  Then C is functionally Dependent on A
Ø  But this type of indirect dependency is known as transitive dependency
Ø  In PART table we are having transitive dependency lies.

PART

PART
NO.
PART
NAME
SUP
NO.
SUP
NAME
SUP
CITY

Ø  Here SUP_NAME,SUP_CITY are dependent upon the SUP_NO field. Again SUP_NO field dependent upon the PART_NO.(C=>B=>A)
Ø  Thus we have to remove this transitive dependency by breaking this PART table into two new tables PART_SUPPLIER & SUPPLIER tables.

THIRD NORMAL FORM

PRODUCT

PROD.
NO.
PRODUCT
NAME
PROD.
COST
101
Generator
10000
102
ENGINE
20000

PRODUCT-PART

PROD.
NO.
PART
NO.
QTY.
USE
101
201
4
101
202
100
101
203
10
102
202
200
102
203
20
102
204
10



To remove transitive dependency the fields like (SUP_NAME,SUP_CITY) transitively dependent upon the SUPNO=>PARTNO have to be removed and to be place in separate table called SUPPLIER.

 

 

PART-SUPPLIER

PART
NO.
PART
NAME
SUP
NO.
201
WHEELS
301
202
BOLTS
302
203
STEEL BAR
301
204
PIPES
303

SUPPLIER

SUP
NO.
SUP
NAME
SUP
CITY
301
STEELCO
BARODA
302
TISCO
TATANAGAR
303
SAIL
INDORE





















Twitter Delicious Facebook Digg Stumbleupon Favorites More