So why is it this way?
More and more, software developers are using Object-relational mapping (ORM) components to abstract the software from the database. Here is a pretty comprehensive list of object-relational mapping software. What this software does is abstract the data relationships from BOTH the software AND from the database, putting that relationship information into various files that are used by the selected ORM implementation. The impact this has is that it is difficult as a consumer/user of the software to write reports directly against the database - because the first step is having to reverse engineer the usage of the tables in the database.
What can be done about it?
I can think of a couple of approaches:
1. The best solution I can think of is that you need to ask the vendor for ERDs for all databases that will be used to store collected metrics.
2. Since there may be some valid intellectual property-related arguments against no. 1 above, the next best approach would be to ask the vendor for the SQL needed to produce specific reports.
3. If neither of the above works, then reverse engineering is the only approach left. I've had success in this area by turning up the debugging on the software and looking for SQL "SELECT" statements in the log files.
1 comment:
The solution to this in TADDM's case was to extrapolate the "impossible to read/query" schema into a series of views (it actually took 2 levels -- building blocks that were combined into views that more or less match the UI). There's a file dist/etc/views/detail_panel_views.txt that helps you figure out what view corresponds to which data in the UI. It could be better, but it's better than nothing.
Post a Comment