Data Structures and Algorithms
Introduction to Data Structures and Algorithms
by Jeff Hunter, Sr. Database Administrator
Software engineering is the study of ways in which to create large and complex computer applications and that generally involve many programmers and designers. At the heart of software engineering is with the overall design of the applications and on the creation of a design that is based on the needs and requirements of end users. While software engineering involves the full life cycle of a software project, is includes many different components - specification, requirements gathering, design, verification, coding, testing, quality assurance, user acceptance testing, production, and ongoing maintenance.
Having an in-depth understanding on every component of software engineering is not mandatory, however, it is important to understand that the subject of data structures and algorithms is concerned with the coding phase. The use of data structures and algorithms is the nuts-and-blots used by programmers to store and manipulate data.
This article, along with the other examples in this section focuses on the essentials of data structures and algorithms. Attempts will be made to understand how they work, which structure or algorithm is best in a particular situation in an easy to understand environment.
A data structure is an arrangement of data in a computer's memory or even disk storage. An example of several common data structures are arrays, linked lists, queues, stacks, binary trees, and hash tables. Algorithms, on the other hand, are used to manipulate the data contained in these data structures as in searching and sorting.
Many algorithms apply directly to a specific data structures. When working with certain data structures you need to know how to insert new data, search for a specified item, and deleting a specific item.
Commonly used algorithms include are useful for:
Searching for a particular data item (or record).
Sorting the data. There are many ways to sort data. Simple sorting, Advanced sorting
Iterating through all the items in a data structure. (Visiting each item in turn so as to display it or perform some other action on these items)
Fast access if index known<
|Ordered Array||Faster search than unsorted array||Slow inserts
|Stack||Last-in, first-out acces||Slow access to other items|
|Queue||First-in, first-out access||Slow access to other items|
|Linked List||Quick inserts
|Binary Tree||Quick search
(If the tree remains balanced)
|Deletion algorithm is complex|
|Red-Black Tree||Quick search
(Tree always remains balanced)
|Complex to implement|
|2-3-4 Tree||Quick search
(Tree always remains balanced)
(Similar trees good for disk storage)
|Complex to implement|
|Hash Table||Very fast access if key is known
Access slow if key is not known
Inefficient memory usage
Access to largest item
|Slow access to other items|
|Graph||Best models real-world situations||Some algorithms are slow and very complex|
An Abstract Data Type (ADT) is more a way of looking at a data structure: focusing on what it does and ignoring how it does its job. A stack or a queue is an example of an ADT. It is important to understand that both stacks and queues can be implemented using an array. It is also possible to implement stacks and queues using a linked list. This demonstrates the "abstract" nature of stacks and queues: how they can be considered separately from their implementation.
To best describe the term Abstract Data Type, it is best to break the term down into "data type" and then "abstract".
When we consider a primitive type we are actually referring
to two things: a data item with certain characteristics and the permissible operations
on that data. An
int in Java, for example, can contain any whole-number
value from -2,147,483,648 to +2,147,483,647. It can also be used with the operators
+, -, *, and /. The data type's permissible operations are an inseparable part of its
identity; understanding the type means understanding what operations can be performed on it.
In Java, any class represents a data type, in the sense that a class is made up of data
(fields) and permissible operations on that data (methods). By extension, when a data storage
structure like a stack or queue is represented by a class, it too can be referred to as a data type.
A stack is different in many ways from an
int, but they are both defined as a certain
arrangement of data and a set of operations on that data.
Now lets look at the "abstract" portion of the phrase. The word abstract in our context stands for "considered apart from the detailed specifications or implementation".
In Java, an Abstract Data Type is a class considered without regard to its implementation. It can be thought of as a "description" of the data in the class and a list of operations that can be carried out on that data and instructions on how to use these operations. What is excluded though, is the details of how the methods carry out their tasks. An end user (or class user), you should be told what methods to call, how to call them, and the results that should be expected, but not HOW they work.
We can further extend the meaning of the ADT when applying it to data structures such as a stack and queue. In Java, as with any class, it means the data and the operations that can be performed on it. In this context, although, even the fundamentals of how the data is stored should be invisible to the user. Users not only should not know how the methods work, they should also not know what structures are being used to store the data.
Consider for example the stack class. The end user knows that push() and pop() (amoung other similar methods) exist and how they work. The user doesn't and shouldn't have to know how push() and pop() work, or whether data is stored in an array, a linked list, or some other data structure like a tree.
The ADT specification is often called an interface. It's what the user of the class actually sees. In Java, this would often be the public methods. Consider for example, the stack class - the public methods push() and pop() and similar methods from the interface would be published to the end user.
Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX, Linux, and Windows server environment. Jeff's other interests include mathematical encryption theory, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 18 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science.
Copyright (c) 1998-2014 Jeffrey M. Hunter. All rights reserved.
All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at firstname.lastname@example.org.
I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.
Last modified on
Wednesday, 28-Dec-2011 14:15:34 EST
Page Count: 75980