This is the most important step and it is the process that I refer to as Reverse engineering!

The best way to correctly build the Access database architecture is to start with the bottom line The reports! outlining the reports you want to end up with. After all, database systems are there to serve and we want information, please!

As an exercise, if you were migrating from a paper based system or an older database system, you may want to lay out all your existing reports in one large table and prioritize which reports you want to rebuild.

Reports for your Access database would include not just the obvious client list Prayed list of products target year organize, invoice or even a frame.

There are 5 main items you might want to compile to help list the reports needed for your Access database system that you might want to consider:

1. Each report should have a name (title) with a brief description to help identify, isolate, and narrow down the end-user requirements. This helps with labels and search functions and features later on (for other parts of Microsoft Access database objects), but it can also group and try to match similar reports.
2. The column headers (fields) for each report should be listed, which will serve as a potential map of all the required fields. Knowing your fields will serve as the structures for your queries (and tables) that it will need to contain.
3. The layout of the fields and any special formatting attributes (ie currency style, bold, red, underline, etc.) will be a useful exercise, as they can reveal how certain values ​​will be stored, including their data types. It will also confirm the ‘Standardization‘ from the data set (in other words, what contact name be a field or possible fact of two fields; first name Y surname?).
4. Sorting and grouping data by a category (if any) will help organize your data into logical sets and how the data will be organized, leading to the decision to understand and plan for all important relational databases (RDBMS).
5. What type of filtering (criteria) will you want? Write it in plain English as a simple sentence. For example, “I would like to list all UK customers for orders placed during January 2011”. From this exercise, he is actually correlating similarities and beginning to define his queries, which will be the basis of each report.

Keep the details consistent (have a template or design guide) and be as specific as possible.

This will help outline the beginning of the database structure for the next two steps (later in this series).

Each report identified with the fields from that report will help determine where its fields should be stored (in a table).

When taking a closer look at a report, using ‘Database Normalization’ concepts, try to break the data information into smaller, more manageable logical units by focusing on a ‘one to many’ relationship that is potentially in place.

For example, a customer can place one or more orders and therefore a ‘one to many’ The relationship is formed between the customer and an order in two (and sometimes more) tables.

Hopefully the above Reverse engineering The process begins to shed some light on this important process and repeats it for each report you want to end up with.

Every report you analyze should reveal common tables that will form the architecture of the database and take you to the next step.

However, before continuing, spend as much time here as necessary.

This is the most important part of the 7 step reverse engineering plan!