Data Dictionary: Surendra Nadh
Data Dictionary: Surendra Nadh
Data Dictionary: Surendra Nadh
SURENDRA NADH
Data dictionary is a central source data in data management system & an interface to data.
DATABASE TABLES VIEWS DATA TYPE TYPE GROUP DOMAIN SEARCH HELP LOCK OBJECTS
DATABASE TABLES
It is the physical structure in the database where data is going to be stored. Different types of database tables are: Transparent tables Pooled tables Clustered tables
Transparent table
There is a single physical table on database for each transparent table. It stores all Application data(Master&transactio n). It has 1 to 1 relation ship towards database.
Pooled table
Here several pooled tables are combined to form a Table-Pool.(table-pool corresponds to physical table on database) These tables are used for storing all customizing data [ex: customizing tables are country codes, region (state or province) codes, reconciliation account numbers, exchange rates, depreciation methods, and pricing conditions], control data (Ex :screen sequence, program parameters). It has a many to 1 relationship with data base tables.
Cluster table
Cluster table is similar to Table Pool.Several tables combined to form a table cluster. They are used to hold data from a few (approximately 2 to 10) very large tables. They would be used when these tables have a part of their primary keys in common, and if the data in these tables are all accessed simultaneously. Rows from the cluster tables are combined into a single row in the table cluster. The rows are combined based on the part of the primary key they have in common. It has a many to 1 relationship with data base tables based on primary key
Cluster table
The CDHDR and CDPOS tables have first four primary key fields in common and are always accessed together As they are stored in cluster CDCLS
Table Components
Technical settings Table Maintenance generator Append & Include structures Indexes
TABLE
field
Data Element
Domain
Value Table: When you define a domain that all the table fields or structure
components referring to this domain should be checked against a certain table. This information can be stored in the domain by entering a value table. The system proposes the value table as check table when you try to define a Foreign Key for the field or component.
i) Data Type: We can create data type in 2 ways a) Elementary Type: Here we specify technical attributes for a
field again by 2 ways either by Specifying Domain(there are around 13000 pre existing domains ) or Predefined Type.
ii.)Further Characteristics:
A search help can be assigned here by directly specifying the name & specify the export parameter of search help in PARAMETERS. Parameter ID:-A field can be filled with proposed values from SAP memory using a parameter ID. Ex: Company Code.(A user only has authorization for company code 0001. This company code is stored in memory at the beginning of a transaction under the corresponding parameter ID. Fields that refer to the data element are automatically filled with the value 001 in all subsequent screen templates). Default Component Name: We can assign default component name here directly. Ex:BAPI.
ii.) Size
Based on Fixed memory size differentiation there are 0 to 4 categories. When a table is created, initial space (an Initial Extent) is reserved in the database. If more space is required at a later time due to data entries, additional memory will be added depending on the selected size category.
With single-record buffering, only the records that are actually read are loaded into the buffer. Single-record buffering therefore requires less storage space in the buffer than generic and full buffering. The administrative costs in the buffer, however, are greater than for generic or full buffering. Considerably more database accesses are necessary to load the records than for the other buffering types.
With Generic buffering, all the records in the buffer whose generic key fields match this record are loaded when one record of the table is accessed. The generic key are primary key fields of table which is buffered.
With full buffering, either the entire table is in the buffer or the table is not in the buffer at all. All the records of the table are loaded into the buffer when one record of the table is read.
Single-record buffering should be used particularly for large tables where only a few records are accessed with SELECT SINGLE. The size of the records being accessed should be between 100 and 200 KB & even several database access is needed for single record buffering. A table should be buffered generically if only certain generic areas of the table are normally needed for processing . EX: Client specific tables (where client field is generic key), Language specific tables. Full buffering is recommended in the following cases: Tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded. However, you should always pay attention to the buffer utilization. Larger tables where large numbers of records are frequently accessed. If these mass accesses can be formulated with a very selective WHERE condition using a Data base index, it could be better to dispense with buffering.
We can search a table for data records that satisfy certain search criteria faster using an index. Types of Index: 2 types a.)Primary index: It is created automatically while creating Database table based on key field assigned. B.)Secondary Index: other than Primary we can further create indexes called Secondary indexes.(which are used for a frequently accessed table) Disadvantages of secondary index:Additional indexes can also place a load on the system since they must be adjusted each time the table contents change. Each additional index therefore slows down the insertion of records in the table.(So for a tables which are written record usually should contain less no. of indexes,used for read only large tables). Unique Index: A unique index does not permit the multiple entries(if multiple entries are created table will be terminated due to data base violation error).
An append structure is a structure that is assigned to exactly one table or structure. There can be more than one append structure for a table or structure. When table is activated, all append structures are searched & then fields of structures are added(along with foreign keys & search help attachments) . Naming Convention: ZZ or YY (prevent conflicts). The new versions of the standard tables are imported after an upgrade, and the fields, foreign key definitions and search help attachments contained in the append structures are added to the new standard tables at activation.
Modifying Tables and Structures : We use the append technique to attach fields to transparent tables and structures.(which can created in display mode,no access key is required). Modifying Data Element Attributes: In the Modification Assistant, you can modify all data element attributes. By using Append Search helps also.
A view can be used in ABAP programs for data selection. The data of a view is derived from one or more tables, but not stored physically
The individual tables are link using JOIN operations There are 4 types of VIEWS: a)Database view. b)Projection view. c)Maintenance view. d)Help view. Database views implement an inner join. The other view types implement an outer join
With an inner join, you only get the records of the crossproduct 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.
Database view:
A database view provides an application-specific view on such distributed data. A database view is automatically created in the underlying database when it is activated.
Application programs can access the data of a database view using the database interface. You can access the data in ABAP programs with both OPEN SQL and NATIVE SQL Selection with a database view is generally faster than access to individual tables. When selecting with views, you should also ensure that there are suitable indexes on the tables contained in the view. A database view may only contain transparent tables
Projection VIEW:
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. A projection view contains exactly one table. You cannot define selection conditions for projection views. There is no corresponding object in the database for a projection view. The R/3 System maps the access to a projection view to the corresponding access to its base table. You can also access pooled tables and cluster tables with a projection view.
Help View:
To create a help view, a view with outer join is needed as selection method of a search help. The selection method of a search help is either a table or a view. If you have to select data from several tables for the search help,we should generally use a database view as selection method.However, a database view always implements an inner join. If you need a view with outer join for the data selection, you have to use a Help view as selection method. All the tables included in a help view must be linked with foreign keys
Maintenance View:
Maintenance views offer easy ways to maintain complex application objects.
A maintenance view permits you to maintain the data of an application object together. The data is automatically distributed in the underlying database tables. The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view. All the tables in a maintenance view must be linked with foreign keys, that is the join conditions for maintenance views are always derived from the foreign key (You cannot directly enter the join conditions as for database views).
Ex:F4UT_OPTIMIZE_COLWIDTH search help exit is used for adjusting the column width of hit list.
Collective Search Help: A collective search help combines several elementary search helps .
(elementary search helps) without modifications. An append is a Collective type by default. A search Help Exit cannot be assigned to Append Search Help
Attach the search help to a data element Attach the search help to a check table Attach the search help to a table field Attach the search help to a screen field
Lock Arguments
The lock argument of a table in the lock object consists of the key fields of the table. The lock argument fields of a lock object are used as input parameters in the function modules for setting and removing locks generated from the lock object definition. When these function modules are called, the table rows to be locked or unlocked are specified by defining certain values in these fields. These values can also be generic. The lock argument fields therefore define which subset of the table rows should be locked.
A lock object name should follow naming convention E<name> and function modules generated are ENQUEUE_<lockobj.name>, DEQUEUE_<lockobj.name>. collected in a local lock container and sent together by calling the function module FLUSH_ENQUEUE. The local lock container can be emptied by calling the function module RESET_ENQUEUE. All the collected lock requests or lock releases are deleted.
THANK YOU
$Reward Awaits For Those who Waits$