History of MySQL

History of MySQL

We started out with the intention of using the mSQL database system to connect to our tables using our own fast low-level (ISAM) routines. However, after some testing, we came to the conclusion that mSQL was not fast enough or flexible enough for our needs. This resulted in a new SQL interface to our database but with almost the same API interface as mSQL. This API was designed to allow third-party code that was written for use with mSQL to be ported easily for use with MySQL.

MySQL is named after co-founder Monty Widenius's daughter, My.

The name of the MySQL Dolphin (our logo) is “Sakila,” which was chosen by the founders of MySQL AB from a huge list of names suggested by users in our “Name the Dolphin” contest. The winning name was submitted by Ambrose Twebaze, an Open Source software developer from Swaziland, Africa. According to Ambrose, the feminine name Sakila has its roots in SiSwati, the local language of Swaziland. Sakila is also the name of a town in Arusha, Tanzania, near Ambrose's country of origin, Uganda.

List of DBMS, RDBMS Databases

What is an DBMS Relation? Codd's Rule

List of DBMS Database

A DBMS is a complex set of software programs that controls the organization, storage, management,
and retrieval of data in a database. DBMS are categorized according to their data structures or types.
It is a set of prewritten programs that are used to store, update and retrieve a Database.

o dBase
o FrontBase
o filePro

List of RDBMS Database

* 4th Dimension
* Adabas D
* Alpha_Five
* CA-Datacom
* CSQL
* Daffodil database
* Dataphor
* DB2
* Derby aka Java DB
* EnterpriseDB
* eXtremeDB
* FileMaker Pro
* Firebird
* Foxpro 2
* Gladius DB
* Greenplum
* H2
* Helix database
* HSQLDB
* Informix
* Ingres
* InterBase
* Kognitio
* Linter
* MaxDB
* Mckoi SQL Database
* Microsoft Access
* Microsoft Jet Database Engine (part of Microsoft Access)
* Microsoft SQL Server
* Microsoft SQL Server Express
* Microsoft Visual FoxPro
* Mimer SQL
* MonetDB
* mSQL
* MySQL
* Netezza
* NonStop SQL
* Openbase
* OpenLink Virtuoso (Open Source Edition)
* OpenLink Virtuoso Universal Server
* Oracle
* Oracle Rdb for OpenVMS
* Paradox
* Pervasive
* PostgreSQL
* Progress 4GL
* Sav Zigzag
* ScimoreDB
* SmallSQL
* solidDB
* SQLBase
* SQLite
* Sybase Adaptive Server Enterprise
* Sybase Adaptive Server IQ
* Sybase SQL Anywhere (formerly known as Sybase Adaptive Server Anywhere and Watcom SQL)
* tdbengine
* Teradata
* TimesTen
* txtSQL
* Valentina (Database)
* Vertica
* VMDS

Note : All the Databases in RDBMS is also a DBMS.

General info in PHP, MySQL

Do you know this?

- E.F. Codd released his Codd's rule in 1970 at the time of working in IBM's San Jose Research Laboratory

- Structured Query Language (SQL), developed by Donald D. Chamberlin and Raymond F. Boyce, for expressing queries at IBM's San Jose Research Laboratory in early 1970's

- Raymond F. Boyce also worked with Codd to develop the Boyce-Codd Normal Form for efficiently designing relational database tables so information was not needlessly duplicated in different tables.

- SQL was initially called as SEQUEL, was designed to manipulate and retrieve data stored in IBM's San Jose Research Laboratory original relational database product, System R.

- SQL language was standardized by the American National Standards Institute (ANSI) in 1986 and ISO in 1987

- MySQL as maintained by Sun Microsystems and it as first public release in November 1996

- MySQL supported in Windows, Mac OS X, Linux, BSD, UNIX operating systems

- MySQL maximum size of DB is Unlimited, Max table size is 2 GB (Win32 FAT32) to 16 TB (Solaris), Max row size 64 KB,
Max columns per row is 3398, Max Blob/Clob size 4 GB (longtext, longblob), Max CHAR size is 64 KB (text), Max NUMBER size 64 bits.

- MySQL is owned and sponsored by a single for-profit firm, the Swedish company MySQL AB, now a subsidiary of Sun Microsystems

- The world's most popular open source database is MySQL Database

History of Edgar Frank "Ted" Codd (RDBMS)

Edgar Frank "Ted" Codd (August 23, 1923 – April 18, 2003) was born on the Isle of Portland, in England. After attending
Poole Grammar School, he studied mathematics and
chemistry at Exeter College, Oxford, before serving as a pilot in the Royal Air Force during the Second World War.
In 1948, he moved to New York to work for IBM as a mathematical programmer.

In 1953, angered by Senator Joseph McCarthy,
Codd moved to Ottawa, Canada. A decade later he returned to the U.S. and received his doctorate in computer science from
the University of Michigan in Ann Arbor.

Two years later he moved to San Jose, California to work at IBM's San Jose
Research Laboratory, Codd first published Codd's Rule in 1970 when he worked at IBM's San Jose Research Laboratory, where he continued
to work until the 1980s.

During the 1990s, his health deteriorated and he ceased work.

Codd received the Turing Award in 1981 and in 1994 he was inducted as a Fellow of the Association for Computing Machinery.

Codd died of heart failure at his home in Williams Island, Florida at the age of 79 on Friday, April 18, 2003.

Codd's 12 rules for RDBMS

E.F.Codd's 12 rules

Codd's 12 rules are a set of thirteen rules (numbered zero to twelve) proposed by Edgar F. Codd,
a pioneer of the relational model for databases, designed to define what is required from a database management system
in order for it to be considered relational, i.e., an RDBMS.

E.F. Codd released his Codd's rule in 1970 at the time of working in IBM's San Jose Research Laboratory


The rules

Rule 0: The system must qualify as relational, as a database, and as a management system.

For a system to qualify as a relational database management system (RDBMS), that system must use its relational facilities (exclusively) to manage the database.

Rule 1: The information rule:

All information in the database is to be represented in one and only one way, namely by values in column positions within rows of tables.

Rule 2: The guaranteed access rule:

All data must be accessible with no ambiguity. This rule is essentially a restatement of the fundamental requirement for primary keys. It says that every individual scalar value in the database must be logically addressable by specifying the name of the containing table, the name of the containing column and the primary key value of the containing row.

Rule 3: Systematic treatment of null values:

The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number", in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.

Rule 4: Active online catalog based on the relational model:

The system must support an online, inline, relational catalog that is accessible to authorized users by means of their regular query language. That is, users must be able to access the database's structure (catalog) using the same query language that they use to access the database's data.

Rule 5: The comprehensive data sublanguage rule:

The system must support at least one relational language that

1. Has a linear syntax
2. Can be used both interactively and within application programs,
3. Supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback).

Rule 6: The view updating rule:

All views that are theoretically updatable must be updatable by the system.

Rule 7: High-level insert, update, and delete:

The system must support set-at-a-time insert, update, and delete operators. This means that data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.

Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.

Rule 10: Integrity independence:

Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications.

Rule 11: Distribution independence:

The distribution of portions of the database to various locations should be invisible to users of the database. Existing applications should continue to operate successfully :

1. when a distributed version of the DBMS is first introduced; and
2. when existing distributed data are redistributed around the system.

Rule 12: The nonsubversion rule:

If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint.

List of Normalization Techniques

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.

Database normalization, sometimes referred to as canonical synthesis, is a technique for designing relational database
tables to minimize duplication of information and, in so doing, to safeguard the database against certain types of
logical or structural problems, namely data anomalies.

For the most part, the first 3 normal forms are common sense.
1. No repeating elements or groups of elements
2. No partial dependencies on a concatenated key
3. No dependencies on non-key attributes

First Normal Form (1NF) - No repeating elements or groups of elements

i. No two rows are identical
ii. Each table entries having single value
iiiv. Eliminate duplicative columns from the same table
iv. Create separate tables for each group of related data and
v. Identify each row with a unique column or set of columns (the primary key).


Second Normal Form (2NF) - No partial dependencies on a concatenated key

* 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.

i. The table must be in 1NF.
ii. A table is 2NF if it is in 1NF and all fields are dependent on the whole of the primary key,
or a relation is in 2NF if it is in 1NF and every non-key attribute is fully dependent on each candidate key of the relation.
iii. None of the non-prime attributes of the table are functionally dependent on a part (proper subset) of a candidate key;
in other words, all functional dependencies of non-prime attributes on candidate keys are full functional dependencies.
For example, consider an "Employees' Skills" table whose attributes are Employee ID, Employee Name, and Skill;
and suppose that the combination of Employee ID and Skill uniquely identifies records within the table.
Given that Employee Name depends on only one of those attributes – namely, Employee ID – the table is not in 2NF.


Third Normal Form (3NF) - No dependencies on non-key attributes

A 3NF definition that is equivalent to Codd's, but expressed differently, was given by Carlo Zaniolo in 1982.

i. The table must be in 2NF.
ii. Remove columns that are not dependent upon the primary key.
iii. Transitive dependencies must be eliminated. All attributes must rely only on the primary key.
So, if a database has a table with columns Student ID, Student, Company, and Company Phone Number, it is not in 3NF. This is because the Phone number relies on the Company. So, for it to be in 3NF, there must be a second table with Company and Company Phone Number columns; the Phone Number column in the first table would be removed.if you have three columns in a single column. A COLUMN IS STUDENT ID , B COLUMN IS STUDENT NAME AND C COLUMN IS STUDENT ADDRESS

A -> B
A -> C
C -> B

Boyce-Codd normal form (BCNF)

A table is in Boyce-Codd normal form (BCNF) if and only if, for every one of its non-trivial functional dependencies,
X -> Y,
X is a superkey—that is,
X is either a candidate key or a superset thereof.


Fourth Normal Form (4NF)
-------------------------

* Meet all the requirements of the third normal form.
* A relation is in 4NF if it has no multi-valued dependencies.

A table is in fourth normal form (4NF) if and only if, for every one of its non-trivial multivalued dependencies
X ->> Y,
X is a superkey—that is,
X is either a candidate key or a superset thereof.

* For example: if you can have two phone numbers values and two email address values,
then you should not have them in the same table.


Normalizing an Example Table

These steps demonstrate the process of normalizing a fictitious student table.
1. First Normal Form: Repeating groups across columns

The designer might attempt to get around this restriction by defining multiple Telephone Number columns:

Customer ID First Name Surname TelNo1 TelNo2 TelNo3

2. First Normal Form: Repeating groups within columns

Storing Multiple Telephone Numbers on a single columns

TelNo
555-403-1659, 555-776-4100

3. First Normal Form: Unnormalized table:

Student# Advisor Adv-Room Class1 Class2 Class3
1022 Jones 412 101-07 143-01 159-02
4123 Smith 216 201-01 211-02 214-01

4. First Normal Form: No Repeating Groups

Tables should have only two dimensions. Since one student has several classes, these classes should be listed in a separate table. Fields Class1, Class2, and Class3 in the above records are indications of design trouble.

Spreadsheets often use the third dimension, but tables should not. Another way to look at this problem is with a one-to-many relationship, do not put the one side and the many side in the same table. Instead, create another table in first normal form by eliminating the repeating group (Class#), as shown below:

Student# Advisor Adv-Room Class#
1022 Jones 412 101-07
1022 Jones 412 143-01
1022 Jones 412 159-02
4123 Smith 216 201-01
4123 Smith 216 211-02
4123 Smith 216 214-01

5. Second Normal Form: Eliminate Redundant Data

Note the multiple Class# values for each Student# value in the above table. Class# is not functionally dependent on Student# (primary key), so this relationship is not in second normal form.

The following two tables demonstrate second normal form:

Students:

Student# Advisor Adv-Room
1022 Jones 412
4123 Smith 216


Registration:

Student# Class#
1022 101-07
1022 143-01
1022 159-02
4123 201-01
4123 211-02
4123 214-01

4. Third Normal Form: Eliminate Data Not Dependent On Key

In the last example, Adv-Room (the advisor's office number) is functionally dependent on the Advisor attribute. The solution is to move that attribute from the Students table to the Faculty table, as shown below:

Students:

Student# Advisor
1022 Jones
4123 Smith


Faculty:

Name Room Dept
Jones 412 42
Smith 216 42

General information & doubts in Javascript and PHP

Hai all,

Simple show hide sample using Show/Hide?

Simple Show/Hide code