what is data dictionary

[Former Member]

hi frienrds

i am deva

what is ddic? what is is the purpose of this?

[Former Member]

Hi

ABAP dictionary is the central repository for creation and management of definitions used in ABAP.

ABAP dictionary is integrated in ABAP workbench and therefore all tools of the workbench like Programs, Screens, function modules can actively access objects defined in data dictionary.

ABAP workbench is an integrated tool for creating an ABAP application.

Type-definitions

Database objects

Services of the dictionary

Functions of the abap dictionary.

The ABAP Dictionary permits a central management of all the data definitions used in the R/3 System without redundancies .

In the ABAP Dictionary you can create user-defined types (data elements, structures and table types) for use in ABAP programs or in interfaces of function modules. Database objects such as tables and database views can also be defined in the ABAP Dictionary and created with this definition in the database.

The ABAP Dictionary also provides a number of services that support program development. This includes

setting and releasing locks(this helps in maintaining the consistency and integrity of data)

defining an input help (F4 help) and

attaching a field help (F1 help) to a screen field are supported.

Type definitions

Analogous to the predefined ABAP types such as C or I , one may define user-defined types in the dictionary.

The following user-defined types are allowed

Data elements: Describe an elementary type by defining the data type, length and possibly decimal places.

Structures: Consist of components that can have any type.

Table types: Describe the structure of an internal table.

Elaboration on the type categories.

There are three different type categories in the ABAP Dictionary:

Data elements (elementary types) Elementary types have no structure. They describe the data type attributes (such as given Dictionary data type, number of places) and information that is relevant for the screen (such as title) of unstructured data objects (variables/fields).

Structures (structured types) Structured types describe the structure and functions of any structured data objects, that is of data structures with components of any type. A component can be a field with an elementary type or can itself be a structure. A table can also be used as a component in a structure. A database table always has a structure and is therefore implicitly a structured type. However, the fields of a database table can only have an elementary type.

Table types Table types describe the structure and functions of internal tables in the ABAP program. Their rows can have any row type. Table types with elementary row type therefore can be defined just the same as multi-dimensional table types (table types with a table type as row type) or table types using structures with table-like components.

Any complex user-defined type may be built using the

previously mentioned basic types.

Database Objects/

Tables and database views can be defined in the ABAP Dictionary.

These objects are created in the underlying database with this definition. Changes in the definition of a table or database view are also automatically made in the database.

Indexes can be defined in the ABAP Dictionary to speed up access to data in a table. These indexes are also created in the database.

Services of ABAP Dictionary

The ABAP Dictionary supports program development with a number of services:

Input helps (F4 helps) for screen fields can be defined with search helps.

Screen fields can easily be assigned a field help (F1 help) by creating documentation for the data element.

An input check that ensures that the values entered are consistent can easily be defined for screen fields using foreign keys.

The ABAP Dictionary provides support when you set and release locks. To do so, you must create lock objects in the ABAP Dictionary. Function modules for setting and releasing locks are automatically generated from these lock objects; these can then be linked into the application program.

The performance when accessing this data can be improved for database objects (tables, views) with buffering settings.

By logging, you can switch on the automatic recording of changes to the table entries.

The ABAP dictionary contains the data definitions (metadata). It is the central information repository for both the application data as well as

the system data. Structures in the dictionary are not only populated with the application( business) data but also the contain system data pertaining to both development and runtime environment.

[Former Member]

Hi,

The database tables,structures,views,search help,domain,data elemnts,type groups are called data dictionary objects which store and manage the data definitions.

U can also refer this link:

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

Thanks

Vasudha

Message was edited by:

Vasudha L

[Former Member]

Data Dictionary

Definition

A data dictionary is a central source of information for the data in a data management system. Its main function is to support the creation and management of data definitions (or "metadata”)

Functions

Management of data definitions

Provision of information for evaluations

Support for software development

Support for documentation

Ensuring that data definitions are flexible and up-to-date

Data Dictionary

Basic Objects of ABAP/4 Dictionary

Objects in the ABAP/4 Dictionary resided on three levels that support their re-usability. These levels are:

1. Tables and structures

2. Data elements

3. Domains

Hierarchy

Fields

Data elements

Domains

Data types

Domains

Describes the technical characteristics of a table field

Specifies a value range which describes allowed data values for the fields

Fields referring to the same domain (via the data elements assigned to them) are changed when a change is made to the domain

Ensures consistency

Eg. Plant

Data Elements

Describes the role played by a field in a technical context

Fields of same semantic meaning can refer to the same data element

Contains the field information

Eg. Sending Plant and Receiving Plant

Tables & Structures

Tables

Represent the Database Tables where data actually resides.

Tables can be defined independently of the database in the ABAP Dictionary.

The fields of the table are defined with their (database-independent) ABAP/4 data types and lengths.

Structures

Are record declarations that do not correspond to a Database Table.

Just like user-defined data type.

Defined like a table and can then be addressed from ABAP/4 programs.

Structures contain data only during the runtime of a program.

Aggregated Objects of ABAP/4 Dictionary

Aggregated’ means consisting of several components. In the ABAP/4 Dictionary, aggregated objects are objects which come from several different transparent tables.

1. Views

2. Search Help

3. Lock Objects

Views (Aggregated Objects)

Tailored to the needs of a specific application

Used to summarize data which is distributed among several tables

The data of a view is not actually physically stored. The data of a view is instead derived from one or more other tables

Search Help (Matchcodes)

A Search help is a tool to help you search for data records in the system

An efficient and user-friendly search aid for cases where the key of a record is unknown

Lock Objects

Simultaneous accessing of the same data record by two users in the SAP system is synchronized by a lock mechanism.

Locks are set and released by calling certain function modules. These function modules are generated automatically from the definition of so-called lock objects in the ABAP/4 Dictionary

Function modules :

Enqueue_<obj name> - to lock the table

dequeue_<obj name> - to release the lock

Demo

Transactions to play with &#61514;

SE11 : Data Dictionary Initial Screen (SE12 Display only)

SE13 : ABAP Dictionary : Technical Settings

SE14 : Database Utility

SE15 : Repository Information System

SE16 : Data Browser

SE17 : General table Display

SE55 : Table View Maintenance

SM30 : Table Maintenance

ABAP/4 Repository Information

The ABAP/4 Repository Information System allows you to obtain information about objects (tables, fields, domains, etc.) in the ABAP/4 Repository.

You can find anything that is used in programs by using the Data Repository

[Former Member]

ABAP/4 Dictionary

The ABAP/4 Dictionary is the central facility in the system where you can create and maintain data declarations, tables, structures and aggregated objects.

Since it is integrated into the ABAP/4 Development Workbench as an active component, any change made in the ABAP/4 Dictionary takes immediate effect in programs affected.

Basic Dictionary Objects

Data elements - contain the semantic definition (e.g. short description) of what is contained w/in a field.

Tables - collection of records of data in fields.

Domains - describe the technical attributes of the table’s fields (e.g. field type, length, value range, etc.).

Structures and Aggregated Objects (Views)

Besides defining tables stored in the database, you can also define the structure of data which occurs when performing calculations in programs, or when passing data between programs.

Structures are defined and activated in the ABAP/4 Dictionary.

While data can be permanently stored in the database, data in structures exists only during the runtime of a program.

Aggregated objects are objects which come from several different tables.

Views are application-specific views of different ABAP/4 Dictionary tables.

Views allow you to gather information from fields of different tables and present it to users in the form they require

If you find this useful award Points

Cheers,

Chandra Sekhar.

[Former Member]

hi

see the following link

http://help.sap.com/saphelp_46c/helpdata/en/4f/991f82446d11d189700000e8322d00/frameset.htm

narasimha

[Former Member]

hi,

In database management systems, a file that defines the basic organization of a database. A data dictionary contains a list of all files in the database, the number of records in each file, and the names and types of each field. Most database management systems keep the data dictionary hidden from users to prevent them from accidentally destroying its contents.

Data dictionaries do not contain any actual data from the database, only bookkeeping information for managing it. Without a data dictionary, however, a database management system cannot access data from the database.

Some common definitions:

1) A catalog of all data held in a database, or a list of items giving data names and structures.

2) A file that defines the basic organization of a database. It will contain a list of all files in the database, the number of records in each file, and the names and types of each field.

3) A database about data and database structures. A catalog of all data elements, containing their names, structures, and information about their usage. A central location for metadata

4) This is a file that defines a file's structure, to include a file's fields and relationship to other files. This is sometimes called schema.

5) A tool used in database management systems to track the tables, fields, field names, field lengths, default settings, validation rules, and relationships.

please reward if useful..

[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.

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.

[Former Member]

A data dictionary is a reserved space within a database which is used to store information about the database itself.

A data dictionary may contain information such as:

Database design information

Stored SQL procedures

User permissions

User statistics

Database process information

Database growth statistics

Database performance statistics

[Former Member]

Purpose of a Data Dictionary: To DOCUMENT for all posterity the data elements, structures, flows, stores, processes, and external entities in the system to be designed.

Guidelines for Developing a Data Dictionary

1. Design a plan for the development, implementation, and continuing maintenance of the data dictionary.

Preplanning is imperative. The development of a data dictionary is part of a larger process. An information model must first be developed to align the workflow with information flow. This includes deciding what data are required, how the data will be used, who will use the data, and how the data will flow internally and externally, including communications with other entities.

This should be a collaborative process, and stakeholders should be encouraged to resist the temptation to collect data simply because they can. In the ideal scenario, data are captured once for use by multiple users. The end result of this data mapping is the ability of multiple entities to mine the same data source. Each will know the exact nature of the data element each is accessing. The plan should also include:

The type of media (paper, electronic, spreadsheet, relational database) in which the data dictionary will be developed and maintained. The media choice may depend on the complexity of the enterprise system and the availability of resources.

Adequate funding and staffing with clearly defined roles and responsibilities for development and ongoing maintenance of the data dictionary. Databases are dynamic and can be affected by new business lines, changes in national standards, and clinical advancements.

Provisions to ensure that all licensing agreements are in order.

Ongoing education and training of all staff as appropriate to their use of data elements and their definitions.

2. Develop an enterprise data dictionary that integrates common data elements used across an enterprise.

One purpose of the data dictionary is to provide consistency and understanding of common data across applications. Preplanning is a must to accomplish this at an enterprise level. A process must be clearly defined and key stakeholders identified. The process requires collecting information or metadata (data about the data) on each data element found to be common across domains. It is important to define up front what needs to be done before starting the dictionary. This includes defining what metadata will be collected on each element as well as what will not be collected. Examples of metadata include name of element, definition, application in which the data element is found, locator key, ownership, entity relationships, date first entered system, date element terminated from system, and system of origin.

A metadata registry is an authoritative source of reference information about the representation, meaning, and format of data collected and managed by an enterprise. It does not contain the data itself but the information that is necessary to clearly describe, inventory, analyze, and classify data.

3. Ensure collaborative involvement and buy-in of all key stakeholders when data requirements are being defined for an information system.

Stakeholders include data creators, data owners, and data users, both internal and external to the organization. Representation should reflect all geographies (departments, facilities, satellites, corporate representatives, and external entities). Each organization must identify its stakeholders based on its own unique business model, organizational structure, information flow, and reporting requirements. Different stakeholders may have different data element definitions within their local domain. Every attempt should be made to promote collaborative agreement whereby a datum is collected only once even though it may be used by multiple end users.

Take for example a large enterprise that discovered it had approximately 40 different representations for data elements with a set of values of “yes” and “no” throughout its data dictionary. These included: Y = yes, N = no; yes, no; 1 = yes, 0 = no; 1 = no, 0 = yes; 1 = yes, 2 = no. These should be standardized as one set of values in the enterprise data dictionary.

Public health and research are examples of external stakeholders. Public health reporting is often forgotten in the data requirements definition phase. As a result, organizations incur extra costs to develop special interfaces and maintain crosswalk tables to meet public health requirements.

The collaboration of all data stakeholders (e.g., clinical specialties, support services, HIM services, IS services, reimbursement specialists, administrative, legal, and public health agencies) should enhance consensus and understanding of data and their flow across all domains.

4. Develop an approvals process and documentation trail for all initial data dictionary decisions and for ongoing updates and maintenance.

It is important to document decisions made about the data dictionary throughout the life of the system. Each subsystem (e.g., finance, lab, radiology) should have one authoritative owner responsible for tracking all implemented data dictionary activations, deactivations, relevant dates, events, and decisions.

There must be a maintenance and change control process for adding new values, elements, and enactment dates. The subsystem owner should review and approve any additions to the system and integrate those changes through a collaborative process with other owners into the whole enterprise system. The process should address how a new datum applies in the local setting or domain and across all aspects of the enterprise.

5. Identify and retain details of data versions across all applications and databases.

Ensure clear mapping instructions for organization-specific definitions. Version control is essential for maintaining data reliability. It is important that the data set version is clearly identified. Differences between versions may be minor or extensive. It is critical that everyone in the enterprise operate on the same version in order to maintain data integrity and continuity. Version control is essential for data dissemination in standard format to satellite or remote facilities. Separate tables may be considered for keeping track of changes such as additions, deletions, and their relative effective dates.

6. Design flexibility and growth capabilities into the data dictionary so that it will accommodate architecture changes resulting from clinical or technical advances or regulatory changes.

Build expansion capabilities into the fundamental design to accommodate a dynamic system. There should be a plan for future expansion, such as expanding a data field from one element to multiple elements. Expansion must be carefully addressed because of the potential ramifications of concept migration, the change of an idea or concept over time through growth or change to the system. This becomes problematic when comparing data across time if the meaning of a particular element has changed while its name or representation has not. If a data element is totally revamped, document when that specific data element went into effect and when it was deactivated. If the data element expands into something new, do not migrate the old concept but rather create a new element to move forward. This will affect how the data are stored and retrieved. It may require consultation with vendors where current system limitations exist.

Always strive for concept permanence. Never reuse a concept even if it becomes obsolete. For example, when an ICD code number is retired, never reassign the retired code to a new concept. Always follow the defined coding practices. This becomes particularly important in data comparison. Address architecture flexibility in vendor contracts to allow for system upgrades and room for expansion to accommodate requirements common to provider-specific issues, user groups (multiple sites), or state-based directives.

7. Design room for expansion of field values over time.

Consider future needs to collapse and expand values to accommodate mapping from a larger to smaller or smaller to larger number of values within a field definition. When setting up the information system, consider how to accommodate multiple systems and how to go from one code system to another. Mapping and transferring guidelines should be clarified between data sets. For example, race or ethnicity is frequently defined with different values. One data set has four items, another has six. The mainframe or core system needs the maximum amount of values. The mapper needs to know the rules to use when collapsing six values into four. Migrating four to six is usually impossible, which creates other issues.

Gender is another core data element that can generate much discussion. Many systems only allow for male and female, while others provide for unknown and other. When an “other” category is an option, there should be a process for monitoring what is captured under that heading. When large numbers begin to appear in the category, there should be a review to determine if a new discrete category is required or if there is misunderstanding in the definition of the core element.

Take for example a data dictionary that must accommodate the changes necessary to adopt the current ICD-9-CM diagnosis code fields from six characters to what will be required for ICD-10-CM. Some organizations have been proactive and already made these changes and updated their data dictionary.

8. Follow established ISO/International Electrotechnical Commission (IEC) 11179 guidelines or rules for metadata registry (data dictionary) construction to promote interoperability and automated data sharing.

Uniformity of approach in data dictionary development avoids industry fragmentation. In an effort to promote and improve international communications among governments, businesses, and scientific communities, ISO and IEC have developed standards for specification and standardization of data elements. The ISO/IEC 11179 standard consists of:

A framework for the generation and standardization of data elements

A classification of concepts for the identification of domains

Basic attributes of data elements

Rules and guidelines for the formulation of data definitions

Naming and identification principles for data elements

Registration of data elements

This standard provides excellent detailed information and examples of how to classify and define data elements. It also includes examples of pitfalls and practices to avoid.

9. Adopt nationally recognized standards and normalize field definitions across data sets to accommodate multiple end user needs.

It is important to define all data characteristics to be included for each data element for all domains. This includes specifying domain boundaries and identifying linkages across domains. This will require extensive discussion and agreement among all stakeholders. The ideal is the development of a common integrated data and terminology model. Terminologies should be coordinated to eliminate overlaps, redundancies, and inconsistencies. This will eliminate the need for mapping among terminologies.

10. Beware of differing standards for the same clinical or business concepts.

Do not assume that things labeled the same are actually identical or will map one to one. For example, there are several different wound staging protocols. The Centers for Medicare and Medicaid Services require one version in the Minimum Data Set Version 2.0 for reimbursement purposes. For clinical care, it requires a different staging protocol that is based on the AHRQ Clinical Practice Guideline for Pressure Ulcers. MDS 3.0, currently in beta with an expected release date in 2007, is expected to remedy this particular problem by requiring only one standard. Pain measurement scales are another example of multiple scales for the same concept. Always check with a subject matter expert to ensure valid data.

11. Use geographic codes and geocoding standards that conform to those established by the National Spatial Data Infrastructure and the Federal Geographic Data Committee, following the guidelines of the Federal Information Processing Standards.

Valid street addresses, zip codes, county, state, and country codes are important to information exchange across systems and geopolitical boundaries. Standardization of geographic codes enhances interoperability of systems. Healthcare uses this information for tracking diseases as well as people. Using internationally accepted standards further enhances the interoperability of systems and the exchange of information. The following are recommended resources for geographic codes:

Federal Information Processing Standards (www.itl.nist.gov/fipspubs)

Federal Geographic Data Committee (www.fgdc.gov)

United States Postal Service (www.usps.gov)

National Spatial Data Infrastructure (www.fgdc.gov/nsdi/nsdi.html)

International Organization for Standardization (www.iso.org)

12. Test the information system to demonstrate conformance to standards as defined in the data dictionary.

Once the data dictionary is completed, a test plan should be developed to ensure that the system implementation supports the data dictionary. This should include sampling data inputs and outputs for conformance, validity, and reliability. This process should also verify interoperability of systems.

13. Provide ongoing education and training for all staff as appropriate to their use of data elements and their definitions.

To ensure consistency of understanding, application, and use of data, it is imperative to provide ongoing education in those definitions. New employee orientation should routinely include exposure to the concepts expressed in the data dictionary.

14. Assess the extent to which the use of the agreed-upon data elements supply consistency of information sharing and avoid duplication.

Ensure simultaneous adoption of new knowledge developed through research and changing terminologies reflective of changes in clinical practice. Specific stakeholders external to most end-user organizations that should be involved in the development and modification of data elements that affect clinical care include all American Board of Medical Specialty recognized specialty societies (e.g., American Academy of Pediatrics and the American Academy of Family Physicians). This evaluation and modification process should be ongoing and involve members of the specialty societies at all stages of the process.

Conclusion

The creation and maintenance of the data dictionary is pivotal to the success of an EHR system. Much thought and effort must go into the planning and the maintenance of this foundational information. Collaboration and buy-in by stakeholders across all domains is critical to the success of the EHR implementation. A process for ongoing maintenance and updates as well as version control must be in place. The upfront design must provide room for change, growth, and expansion over time. Organizations should follow established guidelines such as the ISO/IEC 11179 and the geographic code systems where possible to promote interoperability. Normalization of concepts across end users is an ultimate goal, while any variances in business or clinical concepts should be carefully noted. Once the hard work of the build has been completed, the EHR system should be thoroughly tested to ensure it accurately reflects the standards as defined in the data dictionary

please reward if any of my answer is useful..

[Former Member]

please reward if any of my answer is useful..

[Former Member]

Hi Deva,

DDIC is where all the infromation related to SAP are stored. It can be information related to business - data, even about the SAP itself - like programs.

In DDIC there are many components: like tables, structures,Views, Types, Lock Objects. The tables will have sub components like data element and domains - which gives information regarding the field as what possible values it can take.

<b>The purpose of using it</b> is to store data, program codes, provide locking to data etc.

The link provided below can help you understand it better.

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

[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.