A cursor is used in a procedure, a step-by-step process of retrieving and manipulating data.
The cursor is a pointer to a row in a table or in a set of rows. The cursor can be moved forward and backward. The data in one row can be combined with the data in another row. More than one operation can be performed for the row, then repeated on the next row.
I believe that cursors are not actually a formal part of the Structured Query Language. SQL always works with sets of rows, mini-tables we might say. SQl statements stand alone, they must be used one-at-time. For Microsoft SQL Server, the cursor is part of the Transact-SQL language, for Oracle it is part of PL*SQL.
Some problems require that several changes or calculations must be performed for each row in the set. Especially of interest are processes that compare data in different rows. Sometimes it can be quite difficult, even impossible to define a row that has all of the data needed for a calculation.
Typically when you need to know, "what happened next" you may need a cursor. Sometimes a database could have been defined differently and the cursor avoided, but we don't have the luxury to start over and do it right.
SQLSister is quite correct about the performance issue, whenever you can formulate a problem in terms of set of rows, use a query. I suspect she works with large datasets and heavy user loads where performance is a serious concern. I work with small datasets and light user loads, in the context of an intranet where the occasional cursor has no noticable effect.