Reverse Engineering

jadeIT

Systems Analyst
Local time
Today, 16:06
Joined
Jul 16, 2002
Messages
50
Anyone that has had to reverse engineer an existing database should know that it can be a difficult and complicated task.

Especially when you are dealing with a database that has been made in a less than desirable fashion (eg, poor relationships, no commenting, wierd tablenames and field names, etc).

So I was wondering, is anyone else here is faced with this task? If so, how do you go about the task? What programs do you use or techniques help you understand an existing database?
 
I suppose it really depends on why you are looking at the database. If you are trying to extend its functionality or changing its functionionality.

No easy way.

Generally I have only been involved with extension of functionality and have used a variety of methods. Best one was to utilise the table structure and write new functionality to my standards as far as possible around existing table structure. That way existing capabilities not changed and I did not have to investigate the methodologies used by others.

No easy answer really

Len B
 
Yeah I agree, there is no easy way.

The main reason I started this topic was out of interest tho, just to see what other peoples thoughts on reverse engineering are, as I thought it'd make a good read.

I am currently trying to get a database to have some extra reports.

This is hard because the thing is mannaged by a front end, and there are NO relationships in access, thats right, NONE. The front end is handling the realtionships in code (delphi it looks like) for some reason.

So I am using a Data Modelling program to model the database from scratch. I do this by viewing the reports, using the front-end and analysing the data in the tables to try and figure out the relationships myself. Some are starightforward.. some are down-right weird...

The program is use (Sybase Process Analyser 9) imports the tables from access tho, which is dam handy.
 
I've been involved in several re-engineering projects and I have gone in different directions depending on how much work was involved. Sometimes it is easier to start from scratch with a better data model and rewrite everything, copying some tables and code from the existing db as possible. Other times trying to rebuild from within the existing db.

I guess you have to assess how much work would be involved, how important is it to fully re-engineer vs. band-aiding existing functionality. Ask questions like what is the life expectancy of the db, is it likely to be further developed and expanded over time.

I have done a lot of home remodeling work, and reworking applications is very similar, sometimes it is easier and cheaper to just level the building and start over.

Good luck.
 
Re-engineering a database can be a real bear. I have never yet found the perfect answer. On the other hand, it is not impossible. But I concur with glynch. There is a cost-benefit analysis here, and it is not trivial.

You must assess the frequency with which you are going to try to make updates to this system. At some point, the added cost of building yet another back door into this database is going to eat you alive. Because, you see, there is NEVER such a thing as adding one more report. Like the corn-chips commercial, "You can never eat just one..."

So somewhere along the line, "Reverse Engineering" will have to become "Re-Engineering" - because that will be the only way to reduce the dreadful overhead associated with back-dooring your way into the database.

As to "how do you understand it" - if you don't have a copy of the database manager that was used to build it, you already have one big mark against you. If you also don't have the architectural documentation, that's another mark. If you don't have the functional specifications, that's three marks. How far of a deficit will you accept before tossing your hands in the air and starting over again? (That's a rhetorical question for which the answer is entirely yours.)
 
In this case, there are no docs or anything. I do have access to the front end, but not the code or any developer options or help as such. Only actually using it as if I were a user of the system. So yeah that makes it a difficult project. If I wasnt able to at least use the front-end tho, I would have no way of completing this project.

The report I am making I am down to only three fields which I need to figure out. I've got them all 'working' but the values are incorrect.. this I have to figure out why.

When it comes to reporting is Crystal Reports worth investing in?
 
Crystal is pretty good, but I think that the Access report writer is better. I would only use Crystal if I didn't have an Access front end to put the reports in. Crystal comes with an ActiveX control that you can actually drop on an Access form. You can then use your Access fe to open a report built with Crystal. I did this for one project because they already had a bunch of reports built before I made their fe app.
 
That sounds interesting.

Well in this case I dont have access to the codeo f the front end, but I can tell that it is using crystal reports.

Does this mean I can drag their existing reports into Access and have a look? This will cut hours and hours off my work. How do I do this, what are the file extensions that I need to find and drop into access?
 

Users who are viewing this thread

Back
Top Bottom