what is data dictionary

[Former Member]

how to create data dictionary?

what is the purpose of views in data dictionary?

[Former Member]

Data Dictionnay is Txn SE11.

You can't create a Data Dictionnary but DATA element, tables, view,... all structure which enable to handle datas !

SE11 enable you to check fields in table, to create new element, ...

Erwan

[Former Member]

Hi,

Just login to r/3 server and enter tcode se11.

all the 6 elements here are known as data dic objects.

Viz:-

database table--to create/change/display database table

view--create/change/display for view

data type:-create/change/display data type

type group:-create/change/display type group

domain:-create/change/display

search help:create/change/display search help.

lock object:- create/change/display lock object

The most important object types in the ABAP Dictionary are tables, views, types, domains, search helps and lock objects.

Tables are defined in the ABAP Dictionary independently of the database. A table having the same structure is then created from this table definition in the underlying database.

Views are logical views on more than one table. The structure of the view is defined in the ABAP Dictionary. A view on the database can then be created from this structure.

Types are used in ABAP programs. The structure of a type can be defined globally in ABAP programs. Changes to a type automatically take effect in all the programs using the type.

Lock objects are used to synchronize access to the same data by more than one user. Function modules that can be used in application programs are generated from the definition of a lock object in the ABAP Dictionary.

Different fields having the same technical type can be combined in domains. A domain defines the value range of all table fields and structure components that refer to this domain.

The ABAP Dictionary also contains the information displayed with the F1 and F4 help for a field in an input template. The documentation about the field is created for a data element that describes the meaning of the contents of a table field. The list of possible input values that appears for the input help is created by a foreign key or a search help.

Check the links

http://help.sap.com/saphelp_webas620/helpdata/en/cf/21ea31446011d189700000e8322d00/content.htm

http://help.sap.com/saphelp_webas620/helpdata/en/cf/21ea43446011d189700000e8322d00/content.htm

http://help.sap.com/saphelp_webas620/helpdata/en/90/8d72fbb1af11d194f600a0c929b3c3/content.htm

Regards

[Former Member]

hi

good

Data definitions (metadata) are created and managed in the ABAP Dictionary. The ABAP Dictionary permits a central description of all the data used in the system without redundancies. New or modified information is automatically provided for all the system components. This ensures data integrity, data consistency and data security.

You can create the corresponding objects (tables or views) in the underlying relational database using these data definitions. The ABAP Dictionary therefore describes the logical structure of the objects used in application development and shows how they are mapped to the underlying relational database in tables or views.

The ABAP Dictionary also provides standard functions for editing fields on the screen, for example for assigning a screen field an input help.

What Information is Stored in the ABAP Dictionary?

The most important object types in the ABAP Dictionary are tables, views, types, domains, search helps and lock objects.

Tables are defined in the ABAP Dictionary independently of the database. A table having the same structure is then created from this table definition in the underlying database.

Views are logical views on more than one table. The structure of the view is defined in the ABAP Dictionary. A view on the database can then be created from this structure.

Types are used in ABAP programs. The structure of a type can be defined globally in ABAP programs. Changes to a type automatically take effect in all the programs using the type.

Lock objects are used to synchronize access to the same data by more than one user. Function modules that can be used in application programs are generated from the definition of a lock object in the ABAP Dictionary.

Different fields having the same technical type can be combined in domains. A domain defines the value range of all table fields and structure components that refer to this domain.

The ABAP Dictionary also contains the information displayed with the F1 and F4 help for a field in an input template. The documentation about the field is created for a data element that describes the meaning of the contents of a table field. The list of possible input values that appears for the input help is created by a foreign key or a search help.

http://help.sap.com/saphelp_webas610/helpdata/en/cf/21ea31446011d189700000e8322d00/content.htm

reward point if helpful.

thanks

mrutyun^

[Former Member]

Hi

Importance/Use of views

Join/Projection/Selection w.r.t views

Inner and Outer joins

Types of views

Database view

Projection view

Maintenance view

Help view

Importance/Use of Views

Data for an application object is often distributed on several database tables. Database systems therefore provide you with a way of defining application-specific views on the data contained in several tables. These are called views.

Data from several tables can be combined in a meaningful way using a view (join). You can also hide information that is of no interest to you (projection) or only display those data records that satisfy certain conditions (selection).

A view is a logical view on one or more tables, that is, a view is not actually physically stored, instead being derived from one or more other tables.

The data of a view can be displayed exactly like the data of a table in the extended table maintenance.

Join, Projection and Selection

CROSS PRODUCT
Given two tables TABA and TABB. Table TABA has 2 entries and table TABB has 4 entries

Each record of TABA is first combined with each record of TABB. If a join condition is not defined, the cross product of tables TABA and TABB is displayed with the view.

Join condition

A join condition describes how the records of the two tables are connected.

Inner Join and Outer Join

The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join.
With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view.
With an outer join, records are also selected for which there is no entry in some of the tables used in the view. (ABAP allows left outer join.)

The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join.


Projection

Sometimes some of the fields of the tables involved in a view are not of interest. The set of fields used in the view can be defined explicitly (projection). In our example, Field 4 is of no interest and can be hidden.

We specify the fields which we need to show in our view by including them under the view flds tab when creating a view in the dictionary.


Selection Conditions

Selection conditions that are used as a filter can be defined for a view.

Specifying these conditions under the Selection conditions tab when creating a view in the dictionary would have an effect which is similar to specifying a where clause when writing a select query to restrict data.

View Types

Four different view types are supported. These differ in the way in which the view is implemented and in the methods permitted for accessing the view data .

Database views are implemented with an equivalent view on the database.

Projection views are used to hide fields of a table (only projection).

Help views can be used as selection method in Search help.

Maintenance views permit you to maintain the data distributed on several tables for one application object at one time.

Database Views

Database views should be created if want to select logically connected data from different tables simultaneously.
Database views implement an inner join.
Application programs can access the data of a database view using the database interface. (Just as we write select queries on database tables, we can write them for views as well.)


Includes in Database Views 

An entire table can be included in a database view. In this case all the fields of the included table will become fields of the view (whereby you can explicitly exclude certain fields).

To include one of the tables in the view, enter character * in field View field, the name of the table to be included in field Table and character * again in field Field name on the View fields tab page of the maintenance screen of the view.

You can also exclude individual fields of an included table. If you do not want to include a field of the included table in the view, enter - in field View field, the name of the included table in field Table and the name of the field to be excluded in field Field name.

Inserts with Database Views 

If a database view contains only one single table, data can be inserted in this table with the view .

You have the following options for the contents of the table fields not contained in the view:
If the field is defined on the database with NOT NULL as initial value, the field is filled with the corresponding initial value.

If the field is defined on the database as NOT NULL without initial value, an insert is not possible. This results in a database error.

If the field is not defined on the database as NOT NULL, there will be a NULL value in this field.

Projection Views

Projection views are used to hide fields of a table. This can minimize interfaces; for example when you access the database, you only read and write the field contents actually needed

For the above diagram, fields F3 and F4 are irrelevant, and therefore hidden from the projection view of the table.

Maintenance Views

A maintenance view permits you to maintain the data of an application object together.
The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view.

A maintenance view permits you to maintain the data of an application object together
The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view.


Maintenance Status 

The maintenance status of a view controls whether data records can also be changed or inserted in the tables contained in the view.

The maintenance status can be defined as follows:

Read only: Data can only be read through the view.
Read, change, delete, insert: Data of the tables contained in the view can be
changed, deleted, and inserted through the view.
Read and change: Existing view entries can be changed. However, records
cannot be deleted or inserted.
Read and change (time-dependent views): Only entries whose non-time
dependent part of the key is the same as that of existing entries may be
inserted.

Help Views

Help view is created if a view with outer join is needed as selection method of a search help.

Help views are used exclusively for search helps.
A conventional database view selects data from the database using an inner join.
For a help view however, data is selected using a left outer join.
Eg-> Suppose table SCARR (Airline master table) has AA – American airlines
AB – Air Berlin
AC- Air Canada as three entries.
Table SPFLI (Flight schedule) has entries corresponding only to airlines AA (American airlines) and AB (Air Berlin).

Now if a database view were to be used as a selection method for a search help for airlines, we would only get AA and AB as possible entries because the database view implements an inner join…….If however, we were to use a help view as the selection method here, we would get AA,AB and AC as possible entries because a help view would implement a left outer join.

Restrictions for Maintenance and Help Views

There are some restrictions for selecting the secondary tables of a maintenance view or help view. The secondary tables have to be in an N:1 dependency to the primary table or directly preceding secondary table. This ensures that there is at most one dependent record in each of the secondary tables for a data record in the primary table.

Append Views

Append views are used for enhancements of database views of the SAP standard.

With an append view, fields of the base tables of the view can be included in the view without modifications. This is analogous to enhancing a table with an append structure.

An append view is assigned to exactly one database view. More than one append view can be created for a database view.

The append technique described can only be used for database views. With an append view, only new fields from the base tables contained in the view can be inserted in the view. You cannot insert new tables in the view or modify the join conditions or selection conditions of the view.

[vijy_mukunthan]

hi

regarding the usage of views. To get records from multiple tables without help of view u cant fetch the data. The main use of views is to get data from multiple tables.

Then the creation of data dictionary Tcode is se11 .

The usual procedure is create 1st domain then data element and finally create the data base

Reward points if its us full.

Regards

vijay

[Former Member]

hi,

A data dictionary is a set of metadata that contains definitions and representations of data elements. Within the context of a DBMS, a data dictionary is a read-only set of tables and views.

A software tool for recording the definition of data, the relationship of on category of data to another, the attributes and keys of groups of data, and so forth.

An automated tool for collecting and organizing the detailed information about system components. Data dictionaries maintain facilities to document data elements, records, programs, systems, files, users, and other system components.

A data dictionary is a set of metadata that contains definitions and representations of data elements. Within the context of a DBMS, a data dictionary is a read-only set of tables and views. Amongst other things, a data dictionary holds the following information:

Precise definition of data elements

Usernames, roles and privileges

Schema objects

Integrity constraints

Stored procedures and triggers

General database structure

Space allocations

One benefit of a well-prepared data dictionary is a consistency between data items across different tables. For example, several tables may hold telephone numbers; using a data dictionary the format of this telephone number field will be consistent.

<b>CREATION OF DD</b>

The data dictionary is created when you initially create the database with the CREATE DATABASE command. The data dictionary tables are owned by SYS and are accessed through DBA_, ALL_ and USER_ views. If you want to know what is in your data dictionary, query the appropriate views. Never update the data dictionary manually! Let the database update it when you issue CREATE, ALTER or DROP commands.

<b>TO SEE FIGURES GO TO LINK:

<u>http://www.bcarter.com/tip039.htm</u></b>

A data dictionary is a working tool for programmers and power users who must deal directly with the database. A simple data dictionary is an alphabetic list of tables and columns and their descriptions, and some technical details like data types and default values. Programmers use it to look stuff up, to answer questions about the data. End users do the same thing when they're trying to construct ad-hoc reports.

Figure 1 shows a screen shot of a simple data dictionary. The tables are arranged alphabetically together with concise definitions and some other details. In this example, SQL Anywhere 5 is the DBMS and publish subscribe replication is in use, so these details include the disposition of each table; i.e., where it is created, how it is replicated and so on.

Figure 1:

When an organization builds an enterprise-wide data dictionary, it may include both semantics and representational definitions for data elements. The semantic components focus on creating precise meaning of data elements. Representation definitions include how data elements are stored in a computer structure such as an integer, string or date format (see data type). Data dictionaries are one step along a pathway of creating precise semantic definitions for an organization.

Initially, data dictionaries are sometimes simply a collection of database columns and the definitions of what the meaning and types the columns contain. Data dictionaries are more precise than glossaries (terms and definitions) because they frequently have one or more representations of how data is structured. Data dictionaries are usually separate from data models since data models usually include complex relationships between data elements.

Also included are the names of files to be used for the new SQL Anywhere 5 unload and load commands. These file names start with the letters tn, where n is a number representing hierarchical dependencies. In other words, t2contac means the contact table must be loaded after and deleted before other tables marked t1. This makes it possible to write a simple PowerBuilder application to dump and reload an entire database to and from text files, and have that program driven from the dictionary.

The last line of each table definition describes the end user access privileges, making it possible to automatically generate grant commands from the dictionary.

Each table definition is immediately followed by an alphabetic list of its columns, together with their data types, null versus not null settings, default values and an indication of whether it is part of a primary, foreign and/or alternate key (PK, FK, AK). As with the tables, a concise free-form description appears directly beneath each column name.

Some of these details are specific to the needs of one particular project. Their primary importance is to the human reader, not computer programs. Many of these details are available elsewhere; for example, the data types are visible in the database diagram shown in Figure 2, and the default values and access privileges can be discovered by querying the system catalog. The dictionary serves to gather the important information together in one place and, of course, to provide the table and column descriptions that make a dictionary what it is.

Figure 2: The Contact Table

In this example, ERwin/ERX for PowerBuilder was used to create the database. The ERwin Entity Definition and Attribute Definition editors were used to store the table and column descriptions respectively. As well, the three-part Entity Note/Query/Sample Editor was used to hold specific details about each table as shown in Figure 3. The text entered here may not fit the purpose for which these fields were originally intended, but that doesn't matter; it was easy, it worked, and information entered was useful to the project team.

Figure 3: Using And Abusing ERwin Editors

The main reason to store dictionary information in the database diagram itself is ease of data entry. While it might seem like an oxymoron to claim that ERwin's MultiLineEdit text fields are easy to use when compared with, say, Microsoft Word, the truly difficult data entry task comes when the database changes. It is quite hard to ensure correctness and completeness if the dictionary data is stored separately from the diagram.

If the wrong table and column names appear, if new entries are missing and old entries remain, if the technical details are incorrect the audience will come to mistrust the dictionary. When that happens, as with any documentation that is grossly out of date, it becomes useless and should be abandoned as a waste of time. It is still possible for "garbage in, garbage out" errors to creep in to the text itself but the really big mistakes are avoided by storing it in the diagram.

When it's time to print or display the dictionary, of course, Microsoft Word would be nice. It might be possible to automate a linkage between the diagram and a document via ERwin's DDE facility, or some fancy arrangement involving OLE, but that's where the rubber meets the sky and this is ground level. The dictionary is in the diagram, let's just print it.

ERwin's Entity and Attribute Report facilities provide a way to export the dictionary data to tab-delimited text files. PowerBuilder offers a way to import these files into a database, and the ubiquitous DataWindow can be used to produce final report. Figure 4 shows the layout of two dictionary tables that can be used to provide the link between ERwin and the report. These tables can be stored together with the main database or separately. If you choose the separate database route, you can standardize your dictionary in, say, Watcom SQL or SQL Anywhere even if you're using multiple DBMS's for your applications.

Figure 4: The Dictionary Tables

The trick to exporting ERwin data is to blank out all the fields in the Entity and Attribute Report windows, then check the options in the same order as the columns appear in Figure 4, and finally check the fields labeled Remove Newline and Tab Delimited. To verify your work, have a look at the resulting text files and make sure the column titles on the first line agree with the names in Figure 4.

You can then import these files by hand using the Database Painter or write a PowerBuilder program to automate the task via ImportFile(). In either case, the first line of imported text must be skipped or deleted before the data is saved to the entity and attribute tables.

Once the dictionary data is loaded into the entity and attribute tables, it must be flattened out into a single result set for reporting purposes. This can be accomplished with a DataWindow using the SQL union of two selects shown in Listing 1. Syntax mode is used because it's easier than graphics mode in cases like this. Each column in the first select is given an alias name to force the DataWindow painter to use that as the column name.

Listing 1: The Dictionary Selects

select table_name as table_name,

'' as column_name,

entity_definition as entity_definition,

entity_note as entity_note,

'' as column_datatype,

'' as null_option,

'' as default_value,

'' as pk, '' as fk, '' as ak,

'' as attribute_definition,

sample_instance_data

as sample_instance_data,

query as query

from entity

union

select table_usage,

column_name,

'',

'',

column_datatype,

null_option,

default_value,

pk, fk, ak,

attribute_definition,

'',

''

from attribute

order by 1, 2

With the columns from Listing 1 it is possible to produce the report in Figure 1 with a DataWindow that requires no extra PowerScript code. In other words, it can be run from the DataWindow Painter in Preview mode. Figure 5 shows such a DataWindow in all its glory, complete with computed fields and overlapping columns.

Figure 5: The Dictionary DataWindow

[Former Member]

VIEWS are logical views on more than one table. The structure of the view is defined in the ABAP Dictionary. A view on the database can then be created from this structure.

The followings are different types of views:

- Database View (SE11)

Database views are implement an inner join, that is, only records of the primary table (selected via the join operation) for which the corresponding records of the secondary tables also exist are fetched. Inconsistencies between primary and secondary table could, therefore, lead to a reduced selection set.

In database views, the join conditions can be formulated using equality relationships between any base fields. In the other types of view, they must be taken from existing foreign keys. That is, tables can only be collected in a maintenance or help view if they are linked to one another via foreign keys.

- Help View ( SE54)

Help views are used to output additional information when the online help system is called.

When the F4 button is pressed for a screen field, a check is first made on whether a matchcode is defined for this field. If this is not the case, the help view is displayed in which the check table of the field is the primary table. Thus, for each table no more than one help view can be created, that is, a table can only be primary table in at most one help view.

- Projection View

Projection views are used to suppress or mask certain fields in a table (projection), thus minimizing the number of interfaces. This means that only the data that is actually required is exchanged when the database is accessed.

A projection view can draw upon only one table. Selection conditions cannot be specified for projection views.

- Maintenance View ( SE54 )

Maintenance views enable a business-oriented approach to looking at data, while at the same time, making it possible to maintain the data involved. Data from several tables can be summarized in a maintenance view and maintained collectively via this view. That is, the data is entered via the view and then distributed to the underlying tables by the system.

[Former Member]

HI,

PLEASE REWARD IF ANY OF MY ANSWER IS USEFUL.

[Former Member]

The DDIC is nothing but the ABAP Dictionary. The ABAP Dictionary centrally describes and manages all the data definitions used in the system.

Data types

Data types are the actual type definitions in the ABAP Dictionary. They allow you to define elementary types, reference types, and complex types that are visible globally in the system. The data types of database tables are a subset of all possible types, namely flat structures.

Data Elements

Data elements in the ABAP Dictionary describe individual fields. They are the smallest indivisible units of the complex types described below, and are used to specify the types of columns in the database. Data elements can be elementary types or reference types.

Structures

A structure is a sequence of any other data types from the ABAP Dictionary, that is, data elements, structures, table types, or database tables. When you create a structure in the ABAP Dictionary, each component must have a name and a data type. In an ABAP program, you can use the TYPE addition to refer directly to a structure.

If you define a local data type in a program by referring to a structure as follows:

TYPES <t> TYPE <structure>.

Table Types

Table types are construction blueprints for internal tables that are stored in the ABAP Dictionary.

When you create a table type in the ABAP Dictionary, you specify the line type, access type, and key. The line type can be any data type from the ABAP Dictionary, that is, a data element, a structure, a table type, or the type of a database table. You can also enter a predefined Dictionary type directly as the line type, in the same way that you can with a domain.

Type Groups

Before Release 4.5A, it was not possible to define standalone types in the ABAP Dictionary to which you could refer using a TYPE addition in an ABAP program. It was only possible to refer SAP AG BC - ABAP Programming

Data Types in the ABAP Dictionary to flat structures. Structures in programs corresponded to the structures of database tables or structures in the ABAP Dictionary. In ABAP programs, you could only refer to database tables and structures in the ABAP Dictionary using LIKE. It was, however, possible to refer to individual components of the Dictionary type. Complex local data types such as internal tables or deep structures had no equivalent in the ABAP Dictionary. The solution to this from Release 3.0 onwards was to use type groups. Type groups were based on the include technique, and allowed you to store any type definitions globally in the Dictionary by defining them using TYPES statements.

Views:

There are 4 types views are avilable in SAP.

Database View - To club more than one table

Projection View - To hide fields in one table

Maintanance View - To maintain database records in table

Help View - To provide help for a fields (Same functionality as Search help. This is outdated)

View are improves perfromance in the following aspects

1. If you want to use more than two table in 'JOIN' condition better to use Views . It will improves performance of a program

2. If you want to use mutiple FOR ALL ENTRIES clause, better to club all SELECT statement in a view.

Lock Objects:

Lock objects are use in SAP to avoid the inconsistancy at the time of data is being insert/change into database.

SAP Provide three type of Lock objects.

- Read Lock(Shared Locked)

protects read access to an object. The read lock allows other transactions read access but not write access to

the locked area of the table

- Write Lock(exclusive lock)

protects write access to an object. The write lock allows other transactions neither read nor write access to

the locked area of the table.

- Enhanced write lock (exclusive lock without cumulating)

works like a write lock except that the enhanced write lock also protects from further accesses from the

same transaction.

You can create a lock on a object of SAP thorugh transaction SE11 and enter any meaningful name start with EZ Example EZTEST_LOCK.

Use: you can see in almost all transaction when you are open an object in Change mode SAP could not allow to any other user to open the same object in change mode.

Example: in HR when we are enter a personal number in master data maintainance screen SAP can't allow to any other user to use same personal number for changes.

Technicaly:

When you create a lock object System automatically creat two function module.

1. ENQUEUE_<Lockobject name>. to insert the object in a queue.

2. DEQUEUE_<Lockobject name>. To remove the object is being queued through above FM.

You have to use these function module in your program.

Search Helps:

These are two types.

Elementary n Collective.

1) Elementary search helps describe a search path. The elementary search help must define where the data of the hit list should be read from (selection method), how the exchange of values between the screen template and selection method is implemented (interface of the search help) and how the online input help should be defined (online behavior of the search help).

2) Collective search helps combine several elementary search helps. A collective search help thus can offer several alternative search paths.

3)An elementary search help defines the standard flow of an input help.

4) A collective search help combines several elementary search helps. The user can thus choose one of several alternative search paths with a collective search help.

5)A collective search help comprises several elementary search helps. It combines all the search paths that are meaningful for a field.

6)Both elementary search helps and other search helps can be included in a collective search help. If other collective search helps are contained in a collective search help, they are expanded to the level of the elementary search helps when the input help is called.

See the below link to understand this completely:

http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21ee93446011d189700000e8322d00/frameset.htm

Rewards if useful.