cancel
Showing results for 
Search instead for 
Did you mean: 

Document / Reference for Data Dictionary or Data Model

Former Member
0 Kudos

Does anyone know of a document like a data dictionary that shows the SAP tables, a description (metadata) of what that table is used for and a description of fields in that table?

Accepted Solutions (0)

Answers (5)

Answers (5)

Former Member
0 Kudos

So it appears that the best approach is to reverse engineer the database into Visio or some such tool to get a picture (at least a point in time picture) of how the database is structured.

However, it still seems that KUNNR is used almost universally as the primary key/account number. I find it hard to believe that SAP doesn't have some such document that documents that fact along with other facts about tables and the fields in those tables?

Thanks for all your input so far!

Former Member
0 Kudos

So it appears that the best approach is to reverse engineer the database into Visio or some such tool to get a picture (at least a point in time picture) of how the database is structured.

However, it still seems that KUNNR is used almost universally as the primary key/account number. I find it hard to believe that SAP doesn't have some such document that documents that fact along with other facts about tables and the fields in those tables?

Thanks for all your input so far!

markus_doehr2
Active Contributor
0 Kudos

> So it appears that the best approach is to reverse engineer the database into Visio or some such tool to get a picture (at least a point in time picture) of how the database is structured.

Maybe... but I still don't understand why you want to look at table level to "understand" the software

> However, it still seems that KUNNR is used almost universally as the primary key/account number. I find it hard to believe that SAP doesn't have some such document that documents that fact along with other facts about tables and the fields in those tables?

That document is SE11/SE80

You can also check SE36 (logical database) on how tables are related.

Markus

Former Member
0 Kudos

"Maybe... but I still don't understand why you want to look at table level to "understand" the software :)"

That is a hilarious comment from a software development professional!

A data base should be designed to hold and manage the business rules about the data. Therefore...if a CUSTOMER/PARTY is allowed to have 1:Many ADDRESSES...then a data model would reflect two tables....with a relationship between them (a constraint between the customer and address tables).

By seeing the model, you understand the business rules around the data. By seeing and understanding the business rules...you are in a better position to augment the business rules and or extract the data. I have heard on occasion...that software not only CAPTURED the data...but allowed the end users access to use it! (I'm sure that was a fluke though!)

It does seem like there should be some conceptual data models that educate 'newbies' about the organization of data within SAP. I think the real problem here...is NOT that SAP has 50,000+ tables and is therefore, complex. i think the problem is that there is not a data modeling tool out there that does a great job of managing hierarchies that allows tables to be grouped so that Detail level data models can role up to higher and higher levels of conceptual models.

Former Member
0 Kudos

For some general background on the tables you might want to start here [Important Tables in SAP FI (external site)|http://www.sap-img.com/financial/important-tables-in-sap-fi.htm].

Hope that helps.

J. Haynes

Former Member
0 Kudos

My primary focus is the tables that are "standard" to every SAP database such as the customer master table and it's related tables. I can get a much better grasp on SAP if there were a data model and/or document that showed how the tables work. I could reverse engineer from SQL Server into Visio but that wouldn't give me the description of what the data is supposed to describe.

markus_doehr2
Active Contributor
0 Kudos

> My primary focus is the tables that are "standard" to every SAP database such as the customer master table and it's related tables.

Even that guess is not unambiguous. A system configured as e. g. SAP retail has different (and more) tables than a system configured with IS-OIL. Through the Business Functions more tables and programs can be generated so basically that is not a static thing. ERP 6.0 retrofitted most industry solutions so all those tables are now "standard" - depending on peculiarity.

> I can get a much better grasp on SAP if there were a data model and/or document that showed how the tables work.

I seriously doubt so. The theoretical thought is nice but in reality it's much more complicated. That may work for the old applications (such as FI, CO, SD and MM) - for parts of it, but for everything implemented new it'd be very difficult to understand the context by looking how tables related to each other.

I understand your wish and maybe the single application (MM, SD, whatever) may give you an idea about the underlying data model but since that is developed independently of each other (more or less) it's very unlikely that someone has a full overview over the whole system, its tables and it's data model.

If you just enter an order in VA01 in an IDES system and if you try to track all table accesses via ST05 you'll see how many tables are involved and that it's next to impossible to generate a diagram out of it (not to forget all the customizing tables). There are cluster tables where only the application knows, how to read the data out of it (RAW fields), conditions are stored in pool tables (KAPOL) etc. - most of that stuff is historical. There is also no real normalization of tables so you may have certain data in several tables.

I tried to do such a diagram as an exercise in release 3.1H but I gave up due to the sheer amount of tables and complex interactions between them - that are not described on database level but only on application level (SE11).

Markus

markus_doehr2
Active Contributor
0 Kudos

I doubt that such document exists.

An ERP system has a huge number of tables (> 50.000) which may change from SP level to SP level, it would be a pretty pointless exercise to write a document of it.

What are you looking for?

Markus