Implementing database concepts to develop an application in agile approach : Part 1.1 (Database Concept)
Waterfall vs Agile:
Most of the developers in the world start making their software in the traditional way. Traditional means first they gather most of the requirements of the client and then start designing the database where the data will be stored. After designing the database, which is called Entity-Relationship Diagram (ERD), they start coding. This approach is called waterfall .
This is a very inefficient approach and it is turning obsolete day by day.
New types of thinking and implementations are coming one by one to make a software robust and easily maintainable. The most popular thinking approach now a days is. AGILE
The main part of agile is to start the working without waiting for the whole requirement of the client and evolve the application on the requirement of the client [Details] .
In agile, we don't use 'Requirement' types of word. We rather use 'User Story' as the specification of the software given by the client. I have used a traditional conversation process as the specification of the software.
I am assuming you are familiar with ERD, Basic Programming and you have sound concept on OOP.
If you don't have much confidence on OOP part, i prefer you to go http://tiemoon.blogspot.com here for the primary OOP concept.
Ok. Lets start developing an application for 'ABC University'.
The technical officer of 'ABC University' is Mr. X. Last month he came to me and talked with me about a software for his university.
The conversation was similar to the following one.
[User story:]
Mr. X: “I am the technical officer of ABC University. We admit a lot of students in every semester. So entry down those students is very tough for us in pen and paper. I want to store the information in a computer”
Me: “What data do you want to store for a particular student?”
Mr. X: “Well. I want to store a student’s name, email address, address and phone number”
Me: “Ok. Fair enough. I am going to start developing the software for you”
Entity:
The thing which can be uniquely identified and stored to database is called en entity. It is like an object in OOP concept. The collection of the entity which shares the common characteristics is called the Entity Sets. We can map this concept in OOP as Class.
Analysis:
So in our user story, we can identify Student as an object. So it is an entity and it is the thing that is to be stored.
Notation:
We use a rectangle for expressing an entity in ERD.
Result:
Attribute:
The information we want to store about our entity is called attribute. Any data that will qualify, identify, classify or express the state of entity is called attributes. It can be mapped like the data of an object in OOP.
Analysis:
Since Student is our primary entity, we start analyze its attributes which holds the information of a particular student. And we found a student’s name, email address, address and phone number those are going to be stored for a particular entity.
Notation:
We use an oval to denote an attribute of an entity.
Result:
The table schema is been created. Now we will create it in our database server. I describe it in my next post (1.2)
Most of the developers in the world start making their software in the traditional way. Traditional means first they gather most of the requirements of the client and then start designing the database where the data will be stored. After designing the database, which is called Entity-Relationship Diagram (ERD), they start coding. This approach is called waterfall .
This is a very inefficient approach and it is turning obsolete day by day.
New types of thinking and implementations are coming one by one to make a software robust and easily maintainable. The most popular thinking approach now a days is. AGILE
The main part of agile is to start the working without waiting for the whole requirement of the client and evolve the application on the requirement of the client [Details] .
In agile, we don't use 'Requirement' types of word. We rather use 'User Story' as the specification of the software given by the client. I have used a traditional conversation process as the specification of the software.
I am assuming you are familiar with ERD, Basic Programming and you have sound concept on OOP.
If you don't have much confidence on OOP part, i prefer you to go http://tiemoon.blogspot.com here for the primary OOP concept.
Ok. Lets start developing an application for 'ABC University'.
The technical officer of 'ABC University' is Mr. X. Last month he came to me and talked with me about a software for his university.
The conversation was similar to the following one.
[User story:]
Mr. X: “I am the technical officer of ABC University. We admit a lot of students in every semester. So entry down those students is very tough for us in pen and paper. I want to store the information in a computer”
Me: “What data do you want to store for a particular student?”
Mr. X: “Well. I want to store a student’s name, email address, address and phone number”
Me: “Ok. Fair enough. I am going to start developing the software for you”
Entity:
The thing which can be uniquely identified and stored to database is called en entity. It is like an object in OOP concept. The collection of the entity which shares the common characteristics is called the Entity Sets. We can map this concept in OOP as Class.
Analysis:
So in our user story, we can identify Student as an object. So it is an entity and it is the thing that is to be stored.
Notation:
We use a rectangle for expressing an entity in ERD.
Result:
Figure 1: Entity
Attribute:
The information we want to store about our entity is called attribute. Any data that will qualify, identify, classify or express the state of entity is called attributes. It can be mapped like the data of an object in OOP.
Analysis:
Since Student is our primary entity, we start analyze its attributes which holds the information of a particular student. And we found a student’s name, email address, address and phone number those are going to be stored for a particular entity.
Notation:
We use an oval to denote an attribute of an entity.
Result:
Figure 2: Entity and Attributes
NB: Each of the entity must have a table containing its attribute as the column name.
Naming convention that i will follow through my posts:
- Each of the entity will be in a Noun form. A table will be started with the charactre ‘t’ followed by a underscore ‘_’ and then the entity name. eg: t_Student
- A column will be started with it’s entity name of camel case and then an underscore and then it’s original name. eg: student_Name
So, if we sketch our table structure as a schema, then according to our user story, we will find the table schema as,
t_Student ( student_Name, student_EmailAddress, student_Address, student_Phone)The table schema is been created. Now we will create it in our database server. I describe it in my next post (1.2)
Comments
May be this Will be very helpfull for Us...
Many many Thanks for This kind of posting.