DB Tables Design Question? 1

[gennaroalpha7]

Hello -

There's is report that I want the SQL DB to produce. My question, how can I get the DB to produce the report - the data is not in the DB to produce.

The paper report has 10 columns and between 20 the 40 rows of data from another DB. This report is on paper - what do I need to do to produce the report in a different DB, I do not want to migrate any existing data. Do I need to create new tables? How do i create them - do I use the colomn headings of the paper report?

Thanks for your help.

 

[Andrzejek]

Can you have access to this "another DB" where the original (paper) report's data is coming from? Maybe even not to the entire DB, just to the query that creates that particular report?

I would try this first. This way you don't have to re-create any tables and keep any data on your end.

Have fun.

---- Andy

A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station.

 

[johnherman]

I am not clear about what you want to do. There are tools and techniques to take a report file, parse it, and put it into database tables. Is that what you want? Or do you want to try to migrate the data to the new system. The data that is used to produce the report?

==================================
adaptive uber info galaxies (bigger, better, faster, and more adept than agile innovative cognitive big data clouds)

 

[gennaroalpha7]

Hi,
How can I get the new SQL DB to produce the "paper report".

Do I need to add more tables to the new DB, and relate them, to create the (paper) new report based on the columns of the paper report? How is this process completed?

What are the "tools and techniques to take a report file, parse it, and put it into database tables"?

The original DB is just a really old flat file DB, it's not relational. They use it to produce old reports, and some of those old reports need to go to the new SQL Relational DB. So we have to take a report a get the new system to produce it...I am just trying to understand this process...

Thank you.

Alpha

 

[philhege]

Reports" are produced from the data in a SQL database. The reports themselves don't live there (unless you want to split hairs and include an SSRS instance as part of the "database").

So there are a couple of things in play here:
1. You mention "the original DB". Where does the data live now? Is it still in the flat file? Then you'll have to write an ETL process to bring the data in from the flat file to SQL Server.
2. You'll need an external process to get that flat file to a place that SQL can read.
3. You have to understand the source of the information in your "paper report". What fields supply data to what columns? Is there any intermediate processing or translation? What are the selection criteria? A report definition is crucial.
4. You need a user interface to produce that "paper report" from SQL. The options are many: Excel, SSRS, a custom thick or thin client app, etc. etc.

-----------
With business clients like mine, you'd be better off herding cats.

 

[johnherman]

A couple more points:
1. Relational databases are best when the data has been normalized. So, you need to do a normalization process on your flat file data. That's too deep to go into. If you've never done normalization, you're better off learning about it by reading a book or taking a class, or hiring a consultant to help you learn and build the "data model".
2. In the meantime, the flat file can be loaded into the database, and used to create the report. This will be useful in that the report can be used to validate the new "data model" and normalized data.
3. In the world of relational databases, SQL, Structured Query Language, is usually used to get data out of the database and into reports. If you decide that you don't want to program directly in the SQL language, there are various query tools that will write the SQL for you and run it behind the scenes.

I don't usually endorse products by name, but "Monarch" is a product that can read a report and grab the data. Monarch might be able to help you with the normalization process. Monarch is now owned by

http://www.datawatch.com/

There are probably other competitor products as well, but Monarch has been around since the 90's and is well established.


==================================
adaptive uber info galaxies (bigger, better, faster, and more adept than cognitive innovative agile big data clouds)

 

[Andrzejek]

To get you going on Fundamentals of Relational Database Design, you may want to read this.

Have fun.

---- Andy

A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station.