Documente Academic
Documente Profesional
Documente Cultură
by Dinesh Thakur
Normalization is the process of removing redundant data from your tables in order to
improve storage efficiency, data integrity and scalability. This improvement is balanced
against an increase in complexity and potential performance losses from the joining of
the normalized tables at query-time. 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.
To make database structure flexible i.e. it should be possible to add new data
values and rows without reorganizing the database structure.
Data should be consistent throughout the database i.e. it should not suffer from
following anomalies.
Insert Anomaly - Due to lack of data i.e., all the data available for insertion
such that null values in keys should be avoided. This kind of anomaly can
seriously damage a database
Deletion Anomaly - It leads to loss of data for rows that are not stored else where.
It could result in loss of vital data.
ADVANTAGES OF NORMALIZATION
More flexible data structure i.e. we should be able to add new rows and data
values easily
o Easier to maintain data structure i.e. it is easy to perform operations and complex
queries can be easily handled.
o Minimizes data duplication.
o Close modeling of real world entities, processes and their relationships.
DISADVANTAGES OF NORMALIZATION
o You cannot start building the database before you know what the user needs.
o On Normalizing the relations to higher normal forms i.e. 4NF, 5NF the performance
degrades.
o It is very time consuming and difficult process in normalizing relations of higher
degree.
o Careless decomposition may leads to bad design of database which may leads to
serious problems.
They are
Say I want to create a database which stores my friends name and their top three
favorite artists.
This database would be quite a simple so initially Ill be having only one table in it say
friends table. Here FID is the primary key.
This table is not in normal form why?
FavoriteArtist column is not atomic or doesnt have scalar value i.e. it has having more
that one value.
We have now changed our table and now each column has only one value!! (So whats
left?)
Because here we are having multiple columns with same kind of value.
2. Each table should have information about only one entity so it would be nice if we
store our friends information in one table and his favorite artists information in
another
(For simplicity we are working with few columns but in real world scenario there could
be column like friends phone no, email , address and favorites artists albums, awards
received by them, country etc. So in that case having two different tables would make
complete sense)
FID foreign key in FavoriteArtist table which refers to FID in our Friends Table.
For second normal form our database should already be in first normal form and every
non-key column must depend on entire primary key.
Here we can say that our Friend database was already in second normal form l.
Why?
Because we dont have composite primary key in our friends and favorite artists table.
Composite primary keys are- primary keys made up of more than one column. But there
is no such thing in our database.
But still lets try to understand second normal form with another example
Obviously no.
Yes.
But lets take a break over here and learn some definitions and terms.
So that if value of one column changes the value of other column changes as well.
S.SupplierS.SupplierAddress
In our above example Supplier Address was partially dependent on our composite
key columns (Gadgets+Supplier).
Again we need to make sure that the non-key columns depend upon the primary key and
not on any other non-key column.
Although the above table looks fine but still there is something in it because of which we
will normalize it further.
Artist and No. of tracks are functionally dependent on the Album(primary key).
So in our above table Country column is depended on Artist column which is a non-key
column.
So we will move that information in another table and could save table from redundancy
i.e. repeating values of Country column.
by Dinesh Thakur
DBMS stand for Database Management System, which consist n number of tables
there is no relationship between another table. RDMBS stand for Relational
Database Management System, which having the relationship with other tables. The
Relationship between tables in DBMS is Physical and the relationship in RDBMS is
Logical.
DBMS does not support Data Integrity and RDBMS support Data integrity. RDBMS
support Structural Independence and Advanced Query Capabilities while DBMS does
not support this. DBMS does not support Security while RDBMS supports Security on
Databases. You can not share data between.
Types of DBMS
For simple data manipulation users do not have to write programs, instead the
programs are already written in the database which can be invoked by user by
issuing one or more command in a database language. For more complex
manipulations programming interface is also included in a DBMS.
Most of the currently popular DBMS have more complex architecture. Moreover not
only human users but other programs also can interact with the DBMS. In this
arrangement the database is commonly known as back-end while the user program
is called front-end. Front-end applications can be designed to suite any individuals
or organisations specified data-interaction needs.
With Different types of DBMS can take different approaches manage the data? Each
approach constitutes a database.
by Dinesh Thakur
Database changes over time when information is inserted or deleted. The collection of
information stored in the database at a particular moment is called an instance of the
database. The overall design of the database is called the database schema.
A schema diagram, as shown above, displays only names of record types (entities) and
names of data items (attributes) and does not show the relationships among the various
files.
The schema will remain the same while the values filled into it change from instant
to instant. When the schema framework is filled in with data item values, it is
referred as an instance of the schema. The data in the database at a particular
moment of time is called a database state or snapshot, which is also called the
current set of occurrences or instances in the database
In other words, "the description of a database is called the database schema, which is
specified during database design and is not expected to change frequently". A displayed
schema is called a schema diagram.
A schema diagram displays only some aspects of a schema, such as the namer. of record
types and data items, and some types of constraints. Other aspects are not specified in
the schema diagram. It does not specify the data type of each data item and the
relationships among the various files.
Subschema
A subschema is a subset of the schema and inherits the same property that a schema
has. The plan (or scheme) for a view is often called subschema. Subschema refers to an
application programmer's (user's) view of the data item types and record types, which
he or she uses. It gives the users a window through which he or she can view only that
part of the database, which is of interest to him. Therefore, different application
programs can have different view of data.