S.No
Content
1
Introduction
2
System Analysis
3
4
2. 1
Domain Analysis
2. 2
Existing system
2. 3
Proposed System
2. 4
Feasibility Study
System Requirements Specifications 3. 1
Functional Requirements
3. 2
Non Functional Requirements
3. 3
Software Requirements
3. 4
Hardware Requirements
3. 5
UML Representation for Analysis
System Design 4. 1
Interface Design
4. 2
Architecture Design
4. 3
UML Design Diagrams
Page No.
4. 4
Database Design
5
Software Technology
6
Testing 6. 1
Test Cases
7
Sample Code
8
Input & Output Results
9
Software Development Life Cycle
10
Conclusion
11
Bibiliography
Introduction .
Logistics is the . . . “process of planning, implementing, and controlling the efficient, effective flow and storage of goods, services, and related information from point of origin to point of consumption for the purpose of conforming to customer requirements.“ Logistics is the management of the flow of goods, information and other resources, including energy and people, between the point of origin and the point of consumption in order to meet the requirements of consumers. Logistics involves the integration of information, transportation, inventory, warehousing, material-handling, and packaging, and occasionally security. The logistics and transportation activities are moving towards the centre stage world around and becoming the most critical business function in today’s world of immense competition. Today, quickest and efficient supply chain management is the key success factor for many business sectors. Surface transport still rules as the most widely used mode of logistics in our country. It’s high time; the transportation companies switch to futuristic technology solutions to manage the ever growing industry requirements and never ending customer demands. The solutions that move beyond just logics, towards being efficient, cost effective and quick. The goal of the entire solution is to work as a mini ERP solution for the haulage business entities with minimum investment and maintenance
costs. The benefits aren’t cost alone, it will benefit you to stay ahead by offering high visibility of consignments to your entire team and for the clients. Also assures customer satisfaction, transparency and effective control for the business.
System Analysis
Existing system There is no computerized provision in the company to maintain all the trip details that are taking within the company. All the customer order are being handled manually. A customer has to come up to the company personally to book an order. All the order details are also being maintained manually. The labor work is too much and no proper maintenance is taking place in the existing system.
Problems in Existing System • A considerable amount of effort, time and resources are involved due to manual processing can be achieved. • No proper control over collection of data.
Proposed System The proposed system is an online sales system which will help the company to sell all their products online. When a customer requires a product or multiple products, he issues an order for the products. The proposed system will display an order form, which can be filled by the customer. The proposed system will record the order details as well as the customer details, and generate an appropriate Invoice to be presented to the Customer for order confirmation. Whenever an order is confirmed, then once the payment is done by the customer the product has to be delivered to the customer.
The appropriate transport facilities must be set. The proposed system displays all the vehicles information that are available for delivery. It then allows the to select the vehicle for the door delivery and records all the information regarding the Trip. The proposed system displays a Door Delivery form in which the can add all the information regarding the vehicle, and the customer details to whom the product has to be delivered.
They are a number of vehicles that are used in the company to deliver the order given by the customers. The proposed system will display a vehicle processing form, where the can add all the vehicle details that are available. Also it will add the information of which vehicle has devliered what products and other related information by using the vehicle delivery record form.
Feasibility Study Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. In its simplest term, the two criteria to judge feasibility are cost required and value to be attained. As such, a well-designed feasibility study should provide a historical background of the business or project, description of the product or service, ing statements, details of the operations and management, marketing research and policies, financial data, legal requirements and tax obligations. Generally, feasibility studies precede technical development and project implementation.
They are 3 types of Feasibility
Technology and system feasibility The assessment is based on an outline design of system requirements in of Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified in of volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in of software, hardware, personnel and expertise, to handle the completion of the project •
Whether the required technology is available or not
•
Whether the required resources are available
•
Manpower- programmers, testers & debuggers
•
Software and hardware
Once the technical feasibility is established, it is important to consider the monetary factors also. Since it might happen that developing a particular system may be technically possible but it may require huge investments and benefits may be less. For evaluating this, economic feasibility of the proposed system is carried out. Operational Feasibility Operational feasibility is mainly concerned with issues like whether the system will be used if it is developed and implemented. Whether there will be resistance from s that will affect the possible application benefits? The essential questions that help in testing the operational feasibility of a system are following. •
Does management the project?
•
Are the s not happy with current business practices?
•
Will it reduce the time (operation) considerably? If yes, then they will welcome the change and the new system.
•
Have the s been involved in the planning and development of the project? Early involvement reduces the probability of resistance towards the new system.
•
Will the proposed system really benefit the organization?
•
Does the overall response increase?
•
Will accessibility of information be lost?
•
Will the system effect the customers in considerable way?
Economic Feasibility For any system if the expected benefits equal or exceed the expected costs, the system can be judged to be economically feasible. In economic feasibility, cost benefit analysis is done in which
expected costs and benefits are evaluated. Economic analysis is used for evaluating the effectiveness of the proposed system.
In economic feasibility, the most important is cost-benefit analysis. As the name suggests, it is an analysis of the costs to be incurred in the system and benefits derivable out of the system.
System Requirement Specifications
Functional Requirements Introduction: In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases. In order to show the functional requirements of the software we have to identify the following activities.
SOFTRWARE REQUIREMENTS SPECIFICATION: A Software Requirements Specification (SRS) - a requirements specification for a software system - is a complete description of the behavior of a system to be developed. It includes a set of use cases
that describe all the
interactions the s will have with the software. Use cases are also known as functional requirements. Functional Requirements:
Customer Order Processing •
Add Order Details
•
Add Customer Details
•
Generate Order Report
•
Maintain Orders
•
Search Datewise Orders
Vehicle Maintenance Processing •
Input New Vehicle Information
•
View Trips
•
Manage Door Pickup and Delivery Details
•
Input Customer Details
s Processing •
Adding various Branch Details
•
View Payment Information
•
View/Manage Pending Payments
•
Invoice Controlling
Online Trips Processing •
Maintaing Branch Details
•
View Customer Information
•
Temporary Trips Management
Non Functional Requirements
Non-Functional Requirements describe the aspect of the system that are not directly related to its functional behavior. The different Non-functional requirements for our project are
Performance Requirements: Since the software is online, therefore much of the performance of the system depends on the traffic that is present online and the speed of the Internet. We are trying to give an improved performance by setting cookies to the functions so that when the submits something for the second time, the processing is done much quicker.
Security Requirements: In order to provide security to the data all the different ID’s are completed encrypted and then transferred online. A strong encryption technique is used to encrypt all the sensitive data.
Quality Software Requirements: The software is developed with a very high quality, as the s can find their required data very quickly and efficiently. We will also provide a documentation with which the can use the software very easily.
Software Requirements
Platform:
Windows XP Operating System Server:
Apache Tomcat Web Server Technology:
J2SE (Java 2 Second Edition) and J2EE (Java 2 Enterprise Edition) API:
Java SQL Package (java.sql) Java Servlet Package (javax.servlet) Database: Oracle Front End Design Tool: HTML, DHTML, Dreamweaver, Javascript, Cascading Style Sheets Image Design Tools: Adobe Photoshop
Hardware Requirements
PROCESS
:
PENTIUM IV 2.6 GHz
RAM
:
512 MB DD RAM
MONITOR
:
15” COLOR
HARD DISK
:
20 GB
CDDRIVE
:
LG 52X
KEYBOARD
:
STANDARD 102 KEYS
UML Diagrams
Introduction to UML Unified Modeling Language is the one of the most exciting tools in the world of system development today. Because UML enables system builders to create blue prints that capture their visions in a standard, easy to understand way and communicate them to others. The UML is brainchild of Grady Brooch, James Rumbaugh and Ivar Jacobson. Components of UML: The UML consists of a number of graphical elements that combine to form diagrams. Because it’s a language, the UML has rules for combining these elements. The purpose of the diagrams to present multiple views of the system, and this set of multiple views is called a Model. A UML Model of a system is something like a scale model of a building. UML model describes what a system is supposed to do. It doesn’t tell how to implement the system.
Use Case Diagram: A Use-Case is a description of a systems behavior from a s stand point. For system developer this is a valuable tool: it’s a tried-and-true technique for gathering system requirements from a ’s point of view. A little stick figure is used to identify an actor the ellipse represents use-case functions.
Notations of Use Cases Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.
Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. The arrowheads are typically confused with data flow and as a result I avoid their use.
System boundary boxes (optional). You can draw a rectangle around the use cases, called the system boundary box, to indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not. System boundary boxes are rarely used, although on occasion I have used them to identify which use cases will be delivered in each major release of a system.
Class Diagrams: Class diagrams describe the structure of the system in of classes and objects. Classes are abstractions that specify the attributes and behavior of a set of objects. Objects are entities that encapsulate state and behavior. Each object has an identity: It can be referred individually and is distinguishable from other objects. Basic Class Diagram Symbols and Notations Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes. Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third.
Active Class Active classes initiate and control the flow of activity, while ive classes store data and serve other classes. Illustrate active classes with a thicker border.
Visibility Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all
other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class
Associations Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other. Note: It's uncommon to name both the association and the class roles.
Multiplicity (Cardinality) Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for one company only.
Composition and Aggregation Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate.
Generalization Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class is a specialized version of another. For example, Honda is a type of car. So the class Honda would have a generalization relationship with the class car.
Sequence Diagrams Sequence diagrams describe interactions among classes in of an exchange of messages over time. Basic Sequence Diagram Symbols and Notations Class roles Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list object attributes.
Activation Activation boxes represent the time an object needs to complete a task.
Messages Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks.
Lifelines Lifelines are vertical dashed lines that indicate the object's presence over time.
State Chart Diagrams A statechart diagram shows the behavior of classes in response to external stimuli. This diagram models the dynamic flow of control from state to state within a system. Basic Statechart Diagram Symbols and Notations States States represent situations during the life of an object. You can easily illustrate a state in SmartDraw by using a rectangle with rounded corners.
Transition A solid arrow represents the path between different states of an object. Label the transition with the event that triggered it and the action that results from it.
Initial State A filled circle followed by an arrow represents the object's initial state.
Final State An arrow pointing to a filled circle nested inside another circle represents the object's final state.
Synchronization and Splitting of Control A short heavy bar with two transitions entering it represents a synchronization of control. A short heavy bar with two transitions leaving it represents a splitting of control that creates multiple states.
Activity Diagrams An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation. Because an activity diagram is a special kind of statechart diagram, it uses some of the same modeling conventions. Basic Activity Diagram Symbols and Notations
Action states Action states represent the noninterruptible actions of objects. You can draw an action state in SmartDraw using a rectangle with rounded corners.
Action Flow Action flow arrows illustrate the relationships among action states.
Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object.
Initial State A filled circle followed by an arrow represents the initial action state.
Final State An arrow pointing to a filled circle nested inside another circle represents the final action state.
Branching A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard expression. You can also label one of the paths "else."
Synchronization A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and ing.
Collaboration Diagrams A collaboration diagram describes interactions among objects in of sequenced messages. Collaboration diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system. Basic Collaboration Diagram Symbols and Notations Class roles Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but don't list object attributes.
Association roles Association roles describe how an association will behave given a particular situation. You can draw association roles using simple lines labeled with stereotypes.
Messages Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and instead number messages in order of execution. Sequence numbering can become nested using the Dewey decimal system. For example, nested messages under the first message are labeled 1.1, 1.2, 1.3, and so on. The a condition for a message is usually placed in square brackets immediately following the sequence number. Use a * after the sequence number to indicate a loop.
System Design
A software design document (SDD) is a written description of a software product, that a software designer writes in order to give a software development team an overall guidance of the architecture of the software project. An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, a design document is required to coordinate a large team under a single vision. A design document needs to be a stable reference, outlining all parts of the software and how they will work. The document is commanded to give a fairly complete description, while maintaining a high-level view of the software. The SDD contains the following documents: 1. Architecture Design 2. Interface Design 3. Data Design
System/Architecture Design
3 Tier Architecture Three-tier[2] is a client–server architecture in which the interface, functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms. It was developed by John J. Donovan in Open Environment Corporation (OEC), a tools company he founded in Cambridge, Massachusetts.
The three-tier model is a software architecture and a software design pattern. Apart from the usual advantages of modular software with well-defined interfaces, the three-tier architecture is intended to allow any of the three tiers to be upgraded or replaced independently as requirements or technology change. For example, a change of operating system in the presentation tier would only affect the interface code. Typically, the interface runs on a desktop PC or workstation and uses a standard graphical interface, functional process logic may consist of one or more separate modules running on a workstation or application server, and an RDBMS on a database server or mainframe contains the computer data storage logic. The middle tier may be multi-tiered itself (in which case the overall architecture is called an "n-tier architecture").
Three-tier architecture has the following three tiers:
Presentation tier This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network.
Application tier (business logic, logic tier, data access tier, or middle tier) The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.
Data tier This tier consists of database servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.
Deployment Diagrams Deployment diagrams depict the physical resources in a system including nodes, components, and connections.
Basic Deployment Diagram Symbols and Notations Component A node is a physical resource that executes code components.
Learn how to resize grouped objects like nodes.
Association Association refers to a physical connection between nodes, such as Ethernet. Learn how to connect two nodes.
Components and Nodes Place components inside the node that deploys them.
Interface Design
interface design or interface engineering is the design of computers, appliances, machines, mobile communication devices, software applications, and websites with the focus on the 's experience and interaction. The goal of interface design is to make the 's interaction as simple and efficient as possible, in of accomplishing goals—what is often called -centered design. Good interface design facilitates finishing the task at hand without drawing unnecessary attention to itself. Graphic design may be utilized to its usability. The design process must balance technical functionality and visual elements (e.g., mental model) to create a system that is not only operational but also usable and adaptable to changing needs. Interface design is involved in a wide range of projects from computer systems, to cars, to commercial planes; all of these projects involve much of the same basic human interactions yet also require some unique skills and knowledge. As a result, designers tend to specialize in certain types of projects and have skills centered around their expertise, whether that be software design, research, web design, or industrial design.
Tips for Interface Consistency, consistency, consistency. I believe the most important thing you can possibly do is ensure your interface works consistently. If you can double-click on items in one list and have something happen, then you should be able to double-click on items in any other list and have the same sort of thing happen. Put your buttons in consistent places on all your windows, use the same wording in labels and messages, and use a consistent color scheme throughout. Consistency in your interface enables your s to build an accurate mental model of the way it works, and accurate mental models lead to lower training and costs.
2. Set standards and stick to them:
The only way you can ensure consistency within your application is to set interface design standards, and then stick to them. You should follow Agile Modeling (AM)’s Apply Modeling Standards practice in all aspects of software development, including interface design.
3. Be prepared to hold the line. When you are developing the interface for your system you will discover that your stakeholders often have some unusual ideas as to how the interface should be developed. You should definitely listen to these ideas but you also need to make your stakeholders aware of your corporate UI standards and the need to conform to them.
4. Explain the rules. Your s need to know how to work with the application you built for them. When an application works consistently, it means you only have to explain the rules once. This is a lot easier than explaining in detail exactly how to use each feature in an application step-by-step.
5. Navigation between major interface items is important. If it is difficult to get from one screen to another, then your s will quickly become frustrated and give up. When the flow between screens matches the flow of the work the is trying to accomplish, then your application will make sense to your s. Because different s work in different ways, your system needs to be flexible enough to their various approaches. interface-flow diagrams should optionally be developed to further your understanding of the flow of your interface.
6. Navigation within a screen is important. In Western societies, people read left to right and top to bottom. Because people are used to this, should you design screens that are also organized left to right and top to bottom when deg a interface for people from this culture? You want to organize navigation between widgets on your screen in a manner s will find familiar to them.
7. Word your messages and labels effectively. The text you display on your screens is a primary source of information for your s. If your text is worded poorly, then your interface will be perceived poorly by your s. Using full words and sentences, as opposed to abbreviations and codes, makes your text easier to understand. Your messages should be worded positively, imply that the is in control, and provide insight into how to use the application properly. For example, which message do you find
more appealing “You have input the wrong information” or “An number should be eight digits in length.” Furthermore, your messages should be worded consistently and displayed in a consistent place on the screen. Although the messages “The person’s first name must be input” and “An number should be input” are separately worded well, together they are inconsistent. In light of the first message, a better wording of the second message would be “The number must be input” to make the two messages consistent.
8. Understand the UI widgets. You should use the right widget for the right task, helping to increase the consistency in your application and probably making it easier to build the application in the first place. The only way you can learn how to use widgets properly is to read and understand the -interface standards and guidelines your organization has adopted.
9. Look at other applications with a grain of salt. Unless you know another application has been verified to follow the interface-standards and guidelines of your organization, don’t assume the application is doing things right. Although looking at the work of others to get ideas is always a good idea, until you know how to distinguish between good interface design and bad interface design, you must be careful. Too many developers make the mistake of imitating the interface of poorly designed software.
10. Use color appropriately. Color should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your s may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it. You also want to use colors in your application consistently, so you have a common look and feel throughout your application.
11. Follow the contrast rule. If you are going to use color in your application, you need to ensure that your screens are still readable. The best way to do this is to follow the contrast rule: Use dark text on light backgrounds and light text on dark backgrounds. Reading blue text on a white background is easy, but reading blue text on a red background is difficult. The problem is not enough contrast exists between blue and red to make it easy to read, whereas there is a lot of contrast between blue and white.
12. Align fields effectively. When a screen has more than one editing field, you want to organize the fields in a way that is both visually appealing and efficient. I have always found the best way to do so is to left-justify edit fields: in other words, make the left-hand side of each edit field line up in a straight line, one over the other. The corresponding labels should be right-justified and placed immediately beside the field. This is a clean and efficient way to organize the fields on a screen.
13. Expect your s to make mistakes. How many times have you accidentally deleted some text in one of your files or deleted the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or even days, of work? The reality is that to err is human, so you should design your interface to recover from mistakes made by your s.
14. Justify data appropriately. For columns of data, common practice is to right-justify integers, decimal align floating-point numbers, and to left-justify strings.
15. Your design should be intuitable. In other words, if your s don’t know how to use your software, they should be able to determine how to use it by making educated guesses. Even when the guesses are wrong, your system should provide reasonable results from which your s can readily understand and ideally learn.
16. Don’t create busy interfaces. Crowded screens are difficult to understand and, hence, are difficult to use. Experimental results show that the overall density of the screen should not exceed 40 percent, whereas local density within groupings should not exceed 62 percent.
17. Group things effectively. Items that are logically connected should be grouped together on the screen to communicate they are connected, whereas items that have nothing to do with each other should be separated. You can use white space between collections of items to group them and/or you can put boxes around them to accomplish the same thing.
Data Design
INTRODUCTION: Persistent data and objects that have been derived during the Design is used to develop the database. Storing data in a database enables the system to perform complex queries on a large data set. Where and how the data is stored in the system impacts the system decomposition. The selection of a specific data base management system can also have the implications on the overall control strategy and concurrency management. Entity Relationship Model: An Entity relationship model is a diagrammatic representation of entities, attributes and the relationship among those entities and attributes. Entity Type: Any thing in the real world that has the same characteristics or attributes can be termed as an Entity. For example student can be called as an entity as they have the same attributes such as roll number, name, address etc. Attributes: The characteristics of an entity are called as attributes. Each entity will have its own values for each attribute. For example the attributes for a student entity are roll number, name, address etc. A Student entity such as Ravi will have its own values such as 1, Ravi, Visakhapatnam etc. Entity Set: The collection of entities of a particular entity type are grouped into an Entity Set. For example if employee is the entity type then the collection of all the employees is referred as the entity set. Notations for ER-Diagram: In the ER diagrams the cardinality ration between the entity types can be represented by attaching 1, M, or N on each participating edge. For example the cardinality ratio of Department:Employee for manages is 1:1. The different symbols used to represent the E-R diagram are Rectangles: This symbol represents the each entity type. Double Rectangle: This represent a Weak Entity. Diamonds: These represent the relationship among the entities. Double Diamonds: These represent the identifying relationship between the entities.
Ellipses: These represent the attributes of an entity.
Underlined Ellipse: These represent the key attributes of an entity. Double Ellipse: These represent Multi valued attributes. Dotted Ellipse: This represent Derived attribute. Lines: Lines represent the connection between the attributes to their entities, and also entities to entities.
Normalization The process of analyzing the data to be represented and breaking it down into separate tables in accordance with the principles of relational structure. Need for Normalization Normalization reduces redundancy. Redundancy is the unnecessary repetition of data. It can cause problems with storage and retrieval of data redundancy can lead to inconsistence. Errors are more likely to occur when facts are repeated. Update anomalies inserting, deleting, modifying data may cause inconsistence. There is high likelihood of updating or deleting data in one relation, while omitting to make corresponding changes in other relations. During the process of normalization, we can identify dependence, which can cause problems when deleting or updating. Normalization also helps to simplify the structure of tables to fully normalize record, which should consist of a primary key that identifies that entity is a set of attributes that describes the entity.
Normal Forms Normalization results in the formation of tables that satisfy certain specified constraints and represent certain normal forms. Normal forms are table structures with minimum redundancy.
First Normal Form A relation R is in first normal form if and only if all underlying domains contain atomic values only.
Second Normal Form A relation R is in the second normal form if and only if its is in 1st NF and every non – key attributes is fully dependent on the primary key.
Third Normal Form A relation R is in Third Normal form if and only if it is in SNF and every non-key attributes is not transitively dependent on the primary key.
Fourth Normal Form A relation R is in fourth normal form if and only if whenever there exist a multi-valued dependency is R, say A>>B, then attributes on other attribute is a determinant.
Boyce-codd Normal Form A relation is in Boyce-codd normal form (BCNF) if and only if every determinant is a candidate key. An attribute is fully dependent on other attribute is a determinant.
Fifth Normal Form A relation is in fifth normal form also called project- normal form(PJNF) if and only if the candidate keys of R imply every dependency in R.
DATA DICTIONARY After applying 1st , 2nd, and 3rd Normal form on the above relations we are able to derive the following tables. Table:
create table (name varchar2(20), varchar2(20));
insert into values('','');
----------------------------------------------------------------------
Customers Table:
create table customers ( cid number(5) primary key, cname varchar2(50), varchar2(50), address varchar2(50), name varchar2(50), emailid varchar2(50), phoneno varchar2(50) );
create sequence cidseq start with 1 increment by 1;
create or replace trigger cidinsert before insert on customers for each row begin select cidseq.nextval into :new.cid from dual; end; /
---------------------------------------------------------------------Products Table:
create table products ( pcode varchar2(50), pname varchar2(50), company varchar2(50), qpack varchar2(50), unit varchar2(50), dprice varchar2(50),
price varchar2(50) );
----------------------------------------------------------------------
create table vehicles ( vno varchar2(50), model varchar2(50), year varchar2(50) );
----------------------------------------------------------------------
create table orders ( oid number(5) primary key, cid varchar2(50), pcode varchar2(50), odate varchar2(50), qty varchar2(50)
);
create sequence oidseq start with 1 increment by 1;
create or replace trigger oidinsert before insert on orders for each row begin select oidseq.nextval into :new.oid from dual; end; /
----------------------------------------------------------------------
create table trips ( tid number(5) primary key, oid varchar2(50), vno varchar2(50), tdate varchar2(50), status varchar2(50) );
create sequence tidseq start with 1 increment by 1;
create or replace trigger tidinsert before insert on trips for each row begin select tidseq.nextval into :new.tid from dual; end; /
Software Technology
Technologies Used HTML Hypertext Markup Language (HTML), the languages of the World Wide Web (WWW), allows s to produces Web pages that include text, graphics and pointer to other Web pages (Hyperlinks). HTML is not a programming language but it is an application of ISO Standard 8879, SGML (Standard Generalized Markup Language), but specialized to hypertext and adapted to the Web. The idea behind Hypertext is that instead of reading text in rigid linear structure, we can easily jump from one point to another point.
Basic HTML Tags:
-->
specifies comments
……….
Creates hypertext links
……….
Formats text as bold
……….
Formats text in large font.
…
Contains all tags and text in the HTML document
...
Creates text
…
Definition of a term
...
Creates definition list
…
Formats text with a particular font
Encloses a fill-out form ...
Defines a particular frame in a set of frames
…
Creates headings of different levels( 1 – 6 ) ...
Contains tags that specify information about a document
... Creates a horizontal rule …
