Institutional and Sector Modernisation Facility

ICT Standards

Project Funded by the European Union

ICT Common Codification Schemes Document number: ISMF-ICT/3.08 Version: 1.00

1 Document control

1.1 List of Abbreviations Abbreviation Description CASE Computer Aided Software Engineering CDD Central data Dictionary GDM Government Data Model ISMF Institutional and Sector Modernisation Facility LDM Logical Data Model MoCT Ministry of Communications and Technology SSADM Structure Systems Analysis and Design Method

1.2 Purpose of this Document The purpose of this document is to provide a methodology to achieve common codification schemes (i.e. common data dictionaries, naming conventions and data files) within an Organisation or group of Organisations. This is even more imperative while upgrading the Organisations information infrastructure, moving towards integrated open systems aiming at provide services not only to its employees, but also to the public and / or other institutions (e-services).

2 Introduction It is very usual that within an Organisation or a group of Organizations isolated software applications exist, due mostly to historic reasons (legacy systems). In that case, similar entities (data) or even groups of entities are maintained by the diverse systems to serve their information needs. However, maintaining the same (or similar) data in several systems is often the source of severe problems, such as: � Multiple efforts spent � No single reliable source of information (trusted part) etc To mitigate the problems above, a consolidation of the data used by different systems is highly recommended. This transition often requires an updating of the existing modules, data migration procedures and organisational – institutional measures. Furthermore, inside the Organizations or even the whole public sector (i.e. government) there is a need to impose standards (aiming to facilitate information exchange) in the following areas: � Data elements naming conventions; � Central Data Dictionaries; Creation and maintenance of Central Data Dictionaries must be supported by a specific organizational unit, the Data Management Group.

2.1 Audience The audience of this document consists of: � The public authorities charged with the responsibility to impose standard naming and

related conventions in the Syrian Public Sector; � The data base administrators or other relevant personnel within the Organisation’s

information group; � Administrative personnel, who have the responsibility to maintain the data collections of

the Organisation.

2.2 References Related standards include: � ICT Data Modelling � Systematic assessment of existing systems; � ICT Maintenance; � ICT survey and evaluation; � ICT data migration. Please also refer to “ICT Detailed regulatory measures” document for a description of the Data Management Group proposed responsibilities.

2.3 Overview of Document In the following chapters the document deals with: � Information consolidation transition planning � Information consolidation implementation. References to related standards are made as appropriate. Furthermore, chapter 5 deals with naming conventions for data elements (i.e. attributes, entities, relationships and domains), while chapter 6 deals with the meta-data to be held for data elements in a Government Data Dictionary.

3 Information consolidation transition planning It must be made clear that the achievement of consolidated information within an Organisation or group of organisations is often a very demanding project that should be carefully planned and managed. Therefore, the appropriate notions of the PLC (Project Life Cycle) phases are applicable also in the case of such a project.

3.1 Data collections identification and assessment It is obvious that before proceeding to any data consolidation project, data collections must be identified and assessed.

3.1.1 Data collections identification

Identify the major repositories of data. Guideline 3.1.1 � Use the current application profiles and application documentation to assist in this. Do not

omit major manual data collections; � Only consider permanent data collections that serve a majority of the information needs.

Temporary data sets should be overlooked. Refer to “Systematic assessment of existing systems” for a more detailed presentation of data collections identification

3.1.2 Data Collection Portfolio Assessment

Assess each current data collection with respect to data currency, integrity, redundancy, structure, completeness, access performance etc. Guideline 3.1.2

Consider the following: � Currency. How closely does the data held match the real-time, current data? � Integrity. How accurate is the data? Are there any inconsistencies? � Redundancy. Is key enterprise data created and updated by multiple applications? Do

user files maintain an inordinate amount of extracted data? � Structure. Is the data normalized? � Completeness. Is the data collection complete in terms of the number of records held? � Performance. Does the mechanism support the users' efficient access of data? � Appropriateness. Is the data stored but never used? � Accessibility. Is the data accessible to the users who need it? � Security. Are there sufficient standards and procedures in place to ensure data security?

Not all of the information above is applicable in case of manual or non-structured data.

3.2 Scope of the transition The scope of the transition should be clear thru all of the project phases and stated in the Master Plan, Feasibility Study, Tender and Contract documents (if any), Project Plan, as well as in the Requirements Specification and Analysis documents. Guideline 3.2 The scope usually includes:

Guideline 3.2 � Amendment of the services provided to the Organisation’s “customers” (i.e. public,

enterprises or other institutions) � Integration of services and information systems � Cutting down of the resources needed and allocated to data maintenance Describe in detail how the object will be accomplished. Refer to other related projects. If possible, describe concrete and measurable expected benefits.

3.3 Data maintenance policy development Define in high level: � Who will be the owner of the consolidated data; � How data will be entered and validated; � What will be the users’ access rights. Guideline 3.3 The scope of the transition usually guides the nomination of the data owner. This is the unit which is responsible for the core of the planned services provision. As stated, one of the goals of data consolidation is to provide a “trusted” system. Therefore, the accuracy and completeness of the data are of great importance. Data entry and validation, as well data access procedures and techniques must be carefully designed to achieve this goal.

Page Break

4 Information consolidation implementation The common codification schemes implementation phase consists of the following stages: � Requirements Specification; � Detail Analysis; � Detailed Design; � Data Migration.

4.1 Requirements Specification Not all of the organization’s applications (existing or foreseen) use the same detail of information of a specific data file (either a database table and/or conventional files, e.g. ISAM, sequential etc.) The scope of this phase is to locate the specific needs of each application in terms of information detail. Guideline 4.1 It is obvious that the detail level of the final data file must be the highest detail levelneeded by the existing and/or foreseen applications.

4.2 Detailed Analysis

4.2.1 Architectural choice

During this phase, all the issues related to the building of a common data file are examined, possible risks and resource requirements are evaluated. Guideline 4.2.1 Consider the following issues: � What will be the platform of the new data file (e.g. a database table, an ISAM file etc). Take

into account that: � It is much preferable to build a database table than to maintain an existing

conventional file structure, because of the functionality provided. � On the other hand, when upgrading to a new platform, some applications may become

obsolete and unable to use the new structure, so they will need complete upgrading or replacement.

� Consider also the use of data exchange tools, such as XML and/or integrated hub architectural styles.

For each of the possible solutions, estimate availability, ease of implementation, cost, resources needed, maintainability, risk and benefits.

4.2.2 Data cleansing, data entry requirements

In this section specify the needs regarding data cleansing and data entry. Guideline 4.2.1 Consider the following issues: � Are the data complete and accurate to the desired level of detail? � What will be the needs in terms of data cleansing and/or data entry to obtain a complete

and accurate data file? � Is it possible for different data files to merge into a new one? Are there common

identification fields?

Guideline 4.2.1 � In case of discrepancy, what will be the source of the valid content? Base your decisions on the assessment made in section 3.1.2

4.3 Detailed Design In this section, provide: � A detailed design of the new data file characteristics; � A complete action plan for the transition.

4.3.1 New data file characteristics

The data file characteristics consist of: � The detailed description of the data file (entities, attributes, constraints, relationships); � Possible partitioning specifications; � Primary and secondary key specifications; � Communications; � Security and Maintenance. Guideline 4.3.1 Describe the level of performance required from the system as well as any factors that may affect its operation. This section should include the following information: � the estimated number of maximum, minimum and concurrent users; � identification of the location(s) of the users; � the acceptable response time for a typical system request and � The level of acceptable service interruptions. The requirements above will drive the decisions for: � New hardware – network required � Data partitioning � Secondary key definition Describe the data partitioning scheme that will be implemented and the reasons for doing this. The types of partitioning that are available may depend on the version of the relational database that is being used. Describe the various types of communication that will be required by the system. Where applicable, the following should be included: � the method(s) by which users will interact with the system (e.g. dial-up, local area network,

web); � the method by which information will be gathered by the system in the case that it is

obtained other than by direct user input (e.g., polling other systems to obtain data); and � The method by which the system will distribute information (e.g., distributing data to other

systems without manual intervention). The type of communications described in this section must be consistent with the network model. Describe the procedures for accessing – updating the new data file(s). Describe user roles and access rights.

4.3.2 Implementation action plan

Describe the steps necessary to prepare the system for both user acceptance testing and implementation in a production environment. Define any support required from customers during the build and implementation phases.

Guideline 4.3.2 Produce details relating to the next phase of the project - Migration. Provide a detailed workplan for the next phase identifying all major deliverables and associated tasks (e.g. MS Project). The plan should be in sufficient detail to clearly convey the scope of work that will be performed. Identify the resources and the roles needed for the next phase. This should also include customer resources, a description of their roles, and the estimates by resource of the time they will be required to expend in this phase. Define the costs of the next phase of the project (if applicable)

4.4 Data Migration This is the last phase of the Common Codification Schemes Building. Guideline 4.4 Please refer to “ICT – Data Migration” document for a detailed discussion of data migration procedures.

5 Data naming conventions

5.1 Aim and Scope The aim of this Data Naming Standard is to define the way in which data element names must be constructed for all Information Systems of the Government of Syria. It reflects the thought processes necessary to define a data element name. It seeks to standardise the way in which experienced analysts often make up acceptable names. This Standard is to be used for logical data elements contained in: � the Government Central Data Dictionary (i.e. the Government Data Model data elements),

and � the Project Logical Data Models. Project LDMs will consist of Project-specific data elements (i.e. non-GDM data elements) and of GDM data elements. This standard does not address the naming of physical elements, although it is required that physical names should follow the logical naming conventions wherever possible. In addition, project data dictionaries will associate physical with logical data elements.

5.2 General conventions

5.2.1 Basics

Data element names are made up of a series of ordinary words. There is a need of: � A word that gives the general grouping or context. It might be the entity name, e.g.

PERSON, COMMUNITY, and ELECTION. This is called the Prime Word.

� A word that identifies the general function or purpose of the data, e.g. DATE is used to give a point in time, and NAME is used to identify or classify data. This is called a Class Wordand is usually the last word in the name. It often equates to an SSADM domain.

� A number of words after the Prime Word and before the Class Word to provide the rest of

the meaning. These are called Modifiers. They are sometimes not necessary. If they are necessary, not more than four words are required unless the circumstances are exceptional. For example:

ELECTION_BOOKLET_ISSUE_DATE

(Modifiers in bold)

� A word to expand the Class Word when that does not say enough about the type of data.

This is called a Qualifier because it qualifies the Class Word. It may precede or follow the Class Word. For example:

PERSON_COMMUNITY_CODE

BUILDING_HEIGHT_MEASURE_FEET

(Qualifiers in bold)

The length of Data Names has theoretically no limits. Nevertheless, some limits may be imposed by the software used to maintain the CDD (e.g. SSADM ENGINEER). Abbreviations and Acronyms are used to assist in keeping data element names to 32 characters or less. Abbreviations and acronyms are allowed in logical data element names, as Prime Words, Modifiers, Class Words, or Qualifiers. A list of the currently recommended abbreviations and acronyms is given in Appendix A. Appendix B contains a recommended list of Prime Words, while Appendix C contains a recommended list of Class Words.

5.2.2 Other general conventions

� Data names are to be as concise as possible, but as long as it needs to express a concept fully (i.e. composed of the shortest and smallest combination of words that convey adequately the data element meaning).

� Prepositions and conjunctions are usually omitted to reduce the overall length of a word

without sacrificing meaning. For example ‘OF’ and ‘FOR’ are usually omitted unless they form an essential part of the phrase.

� Similar data names should maintain a similar word-order to assist a readers’ intuitive grasp

that similar worded names have similar meaning. For example: ORG_PERIOD_2_VAT_QUANTITY_LIABLE ORG_PERIOD_2_VAT_QUANTITY_PAID not ORG_VAT_PERIOD_2_QUANTITY_LIABLE ORG_PERIOD_2_VAT_PAID_QUANTITY

� All names must be formed only of UPPERCASE alphabetic characters, with words

separated by the underscore character (delimiter). Blanks and other special characters are not allowed. Numeric characters are not allowed except when the number identifies the element’s position in a set (see example above).

� There must be no reference to a physical location or system in a data name. The name

must make no reference to any computer screen, form or report in which the data element is used.

� The data name must not contain an active verb. � Data names must be unique within their models and data element type (e.g. Attribute,

Domain). This means that:

(1) Names of data elements that are part of the Government Data Model, must be unique within the GDM (i.e. throughout all subsets of the various systems included in the GDM). (2) Names of data elements that are not part of the Government Data Model (i.e. they are project-specific), must be unique within the project data model.

� Plurals of component words are not allowed unless:

(1) They are Qualifiers denoting units of measure, e.g.:

DAYS, KILOMETERS (2) They appear in an approved phrase or abbreviation

� Full words must be used, unless an approved abbreviation or acronym (see Appendix A) exists for a word.

Words used must be in the English Language and in Latin characters. For instance: PERSON_IDENTIFICATION_CARD

5.3 Attributes

5.3.1 Format

PRIME WORD_ MODIFIER_ QUALIFIER_ CLASS WORD_QUALIFIER mandatory 1 word

optional up to 4 words

optional up to 2 words

mandatory 1 word

optional up to 2 words

5.3.2 Reference to Entity

Attribute names will usually contain the reference to the Entity in which they occur. If they are a key they will contain the reference to the Entity of which they are the key. The reference to the Entity, which may not be the complete Entity name, is included to avoid confusion if they are taken out of context. If length is a problem, even with the abbreviated Entity name, the Entity name may have to be omitted.

Example:

PERSON

PASSPORT

PERSON_IDENTIFICATION_NUMBER

PASSPORT_NUMBER PASSPORT_ISSUE_DATE PERSON_IDENTIFICATION_NUMBER

5.4 Entities

5.4.1 Format

PRIME WORD_ MODIFIER mandatory 1 word

optional up to 4 words

5.4.2 Conventions

Furthermore, Entities, being groupings of data describing business objects of interest to the organisation at a logical level, are governed by the general naming conventions. However, an entity name will normally consist of a Prime Word and a number of Modifiers. Additional rules for naming entities are: � Names must be meaningful and unambiguous; � Names must be singular;

5.5 Domains

5.5.1 Format

QUALIFIER_ CLASS WORD_ QUALIFIER optional up to 2 words

mandatory 1 word

optional up to 2 words

5.5.2 Conventions

A Domain is used to define validation, formatting rules, permitted values and classes which are common to more than one attribute. Domain hierarchies may be created with Domain super-types and sub-types. A Domain at the highest level will normally be named with a Class Word and will not include any Qualifiers. Examples of Domains at the top level include:

DATE, NAME Domain sub-types are further defined by Qualifiers. For example:

SYRIAN_DATE, INTERNATIONAL_DATE

NAME_LATIN_CHARACTERS, NAME_ARABIC_CHARACTERS

5.6 Relationships

5.6.1 Format

ENTITY NAME_ LINK PHRASE_ ENTITY NAME (Subject Entity) mandatory

mandatory (Object Entity) mandatory

5.6.2 Conventions

Relationships between Entities must be identified by a unique identifier, which at a physical level may be numeric and system generated that are implemented as Foreign Keys, but at the logical level they must be meaningful in terms of the link between the Master and Detail

Entities. Relationship names are useful for conveying the role of the business relationship between two entities. This is especially true when more than one relationships exist between two entities. Each Relationship is defined by two Relationship Names, one reflecting the perspective from the Master to the Detail and the other reflecting the perspective from the Detail to the Master. The format for both Relationship names is the same, the only difference being that the Subject and Object Entities in the one are reversed in the other. The Link Phrase is made up of three parts: � the words ‘MUST BE’ or ‘MAY BE’ to indicate optionality;� a phrase in the form of a past participle to produce a passive statement about the Subject

Entity; � The words ‘ONE AND ONLY ONE’ or ‘ONE OR MORE’ to indicate degree (or cardinality). To make it meaningful it should be read as a complete phrase starting with ‘Each’ and using the plurals of the Entities when a many relationship is involved. For example:

PERSON

PASSPORT

Subject Entity Optionality Passive Statement Degree Object Entity

Each PERSON_MAY_BE_HOLDER_OF_ONE_OR_MORE_PASSPORTs Each PASSPORT_MUST_BE_OWNED_BY_ONE_AND_ONLY_ONE_PERSON

6 Data definition framework

6.1 Aim and scope The aim of this Data Definition Framework Standard is to define the data which must be used to describe the logical data elements (i.e. the meta-data) contained in: � the Government Central Data Dictionary (i.e. the Government Data Model data elements),

and � the Project Logical Data Models. Project LDMs will consist of Project-specific data elements (i.e. non-GDM data elements) and of GDM data elements. This standard covers names for the following data elements in a logical data model: � Attribute; � Entity; � Domain; � Relationship; It does not address the definition of physical elements. Project data dictionaries will define physical aspects of data elements. The definition and implementation of the Central Data Management Strategy should be the responsibility of the Data Management Group within the Data Processing Services Department. The Data Management Group is, inter alia, responsible for the definition and maintenance of Data Management Standards. The Data Management Group should also be responsible for the creation and maintenance of the Central Data Dictionary which will hold all core meta-data, i.e. definitions of data elements which are common to more than one Government Information System. The Central Data Dictionary can be held in a CASE tool (e.g. SSADM ENGINEER).

6.2 Attributes This section describes the properties which are to be held to describe an Attribute. How each property is to be held in SSADM ENGINEER (as an example) is also shown. SSADM ENGINEER: Record all properties on Data Item Form, unless indicated otherwise.

6.2.1 Name

Logical Name (Mandatory)

Provides an unambiguous method of referring to an attribute. The name must conform to Data Naming Standard 801. SSADM ENGINEER: Record in Name field. Business Name (Optional)

Ideally each attribute should be identified by a single name, that being the Logical Name. However, more than one name may exist for an attribute for reasons of common business usage (i.e. the attribute is already known by a certain name to various business circles) or length (i.e. 32 characters are not enough to express the attribute meaning adequately in the

Logical Name). We record these additional names as Business Names. Business Names are not required to conform to Data Naming Standard 801. They include: � Locally used names; � Prompts on screens and labels on reports if they are substantially different; � Names in common use; � Names in published standards; � Names by which the attribute may be known outside the Government/DPSD. SSADM ENGINEER: Record in the Description field.

6.2.2 Usage (CDD: Mandatory, Project LDM: Inapplicable)

Identification of the information systems that use the attribute. This includes systems at all stages of the systems development life-cycle. SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options.

Form Type (Ref): USAGE Form Name: System User

6.2.3 Entity (mandatory)

The attribute will normally be part of a Logical Data Model and will therefore belong to one or more entities (depending on whether it is a key). It is possible that, in the Central Data Dictionary only, attributes will be included that are not assigned to an entity. SSADM ENGINEER: Record as a relationship, using Associations⌫Entity menu options.

6.2.4 Description (mandatory)

A textual description of the attribute. The description should be worded without assuming any prior knowledge of the reader. If the definition has been extracted from a formal source the description should read exactly as in the source. SSADM ENGINEER: Record in Description field.

6.2.5 Synonyms (optional)

An alternative name used by an information system(s) for the same attribute (i.e. different name, same attribute definition). Synonyms must conform to Data Naming Standard described in chapter 5. Also, more than one Synonyms may exist for an attribute. SSADM ENGINEER: Record as a relationship, using Associations ⌫Synonyms menu options

6.2.6 Data Format and Length (Mandatory)

Note: This property must not be explicitly specified when the attribute: � is related to a Domain, and therefore it inherits Data Format and Length from the Domain,

or

� is a Foreign Key (or part of one) that inherits Data Format and Length from the target primary key.

The format (i.e. data type) and length of the attribute e.g. CHARACTER, 6, and whether it can be signed (positive only, or positive and negative) when relevant. Valid data types include:

CHARACTER (for alphabetic, numeric, special characters), DATE (for numeric characters), INTEGER (for numeric characters - integers), DECIMAL (for numeric characters - real numbers)

SSADM ENGINEER: Record using Window⌫Domain menu options, and Data Type fields.

6.2.7 Data Format Mask (Optional)

A format mask holds additional attribute formatting information, such as character type and position, special characters used for presentation, and structure in the case of simple attributes that are held in a structured format (see section 6.2.8) e.g. date attributes. To express the format mask the following may be used:

X (for occurrence data made of alphanumeric characters), A (for occurrence data made of alphabetic characters), 9 (for occurrence data made of numeric characters),

Alphanumeric and special characters used mainly for presentation, e.g. hyphen (-), credit symbol (CR),

Examples, e.g. 25-05 11:55 (Day + Month + Hours + Minutes) to express the components of a simple attribute that is held in a structured format The characters specified must be compatible with the Data Format specified in section 6.2.6. For instance, if Data Type is Integer, then Storage Mask cannot contain alphabetic symbols e.g. as in 99AAA99. There are two types of Data Format Masks: a. Storage Mask. For example: The attribute of CERTIFICATE_NUMBER may be stored in alphanumeric format. The storage mask shows which characters are alphabetic and which numeric (AA9999999). SSADM ENGINEER: Record using Window⌫Domain menu options, and Validation Description field. b. Presentation Mask. For example: A date may be presented (by output devices) with slashes in fixed places. A presentation format mask to express this is 99/AAA/9999. Alternatively, a date attribute may be expressed as 25 Aug 1993; notice this mask defines the components of a simple attribute that is held in a structured format, the components’ order, the character type and position, and the special characters used (i.e. the spaces). SSADM ENGINEER: Record using Window⌫Formatting menu options, and/or Picture and/or Date Format and/or Numeric Format fields.

6.2.8 Structured Attributes (Optional)

Some attributes are themselves composed of other attributes, i.e. they are a concatenation of simple attributes (these also exist on their own). For example, PROPERTY_ID_NUMBER may be made up of:

AREA_ID_NO + BLOCK_ID_NO + PROPERTY_SERIAL_NO The first two parts are attributes in their own right used in other entities. In these cases the composition must be explained with reference to these attributes. The third attribute is not a separate attribute therefore its’ definition must be explained within the context of the structured attribute. Structured attributes are also known as ‘faceted’ attributes. Generally structured attributes are to be avoided unless there is a good business reason for using them. For instance, where the attribute is a key it will be recommended to hold it in the form of a Composite Key (i.e. a number of individual/simple attributes) rather than as a single key (structured attribute). SSADM ENGINEER: Record in Description field.

6.2.9 Data Values and Ranges (Optional)

The discrete values an attribute may take, or the possible ranges of values. SSADM ENGINEER: Record using Window⌫Domain menu options and Value List or Minimum and/or Maximum fields.

6.2.10 Domain (Optional)

Where an attribute is related to a Domain, the attribute will inherit all the properties of that domain. The Central Data Dictionary will contain a list of domains, together with their properties. SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options.

Form Type (Ref): DOMAIN Form Name: Domain Definition

6.2.11 Validation (Optional)

Any validation/business rules related to the entry or updating of the attribute value, which are not held as data values and ranges (see section 6.2.9), or as validation rules of an associated domain (see section 6.2.10), or as data derivation algorithms (see section 6.2.13). The validation may be expressed by reference to another attribute value. For example:

MARRIAGE_DATE must be later than MARRIAGE_ENGAGEMENT_DATE for the same MARRIAGE entity occurrence SSADM ENGINEER: Record as a relationship, using Associations⌫Modules ⌫Module Set (Validation) menu options. A module set with the same name as the attribute name must be defined first, using Module Sets Form.

6.2.12 Source (Mandatory)

Note: This property must not be explicitly specified when the attribute is a Foreign Key (or part of one) that inherits the Source from the target primary key. The published standard or procedural document which defines the role and characteristics of the attribute, or, the authoritative source which supplied the definition to the Central Data Dictionary or project. The CDD itself may be a Source for an attribute. For example, the Source of OCCUPATION_CODE attribute may be a publication called ‘International Codes of Occupations’. SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options.

Form Type (Ref): SOURCE Form Name: Definition Source

6.2.13 Data Derivation (Optional)

If the data is derived, the algorithm or business rule must be recorded. Derived attributes should only be recorded if there is an over-riding business reason for their inclusion. As an example, the formula used to derive the attribute of PASSPORT_EXPIRY_DATE could be:

PASSPORT_ISSUE_DATE + PASSPORT_DURATION_NUMBER_YEARS SSADM ENGINEER: Record in Description field.

6.2.14 Ownership (Mandatory)

Ownership relates to both meta-data and occurrence-data. Ownership information may not be known at an early stage of definition and may be completed at a later date (as for many other properties). a. Ownership of Meta-data. This relates to the authority responsible for the decisions related to the definition of the attribute. Two properties are held: (1) Ownership Authority. Normally the Government Ministry / Department responsible for the relevant business area. There can be only one Ownership Authority. For example, Ministry of Interior, Registry is the Ownership Authority for the attribute: PERSON_IDENTIFICATION_NUMBER No other Department can change the definition of that attribute. SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options.

Form Type (Ref): OWN_AUTH (Ownership Authority) Form Name: Meta Data Owner Authority

(2) Data Steward. The person within the Ownership Authority who is responsible for Data Management matters and who is the prime point of contact.

SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options.

Form Type (Ref): STEWARD Form Name: Meta Data Steward

b. Ownership of Occurrence Data. This relates to the authority for maintaining the actual values of the attribute. This will often be the same as the Ownership Authority of meta-data, but, may sometimes be a business area using the data. In certain cases, an attribute may be associated with more than one Ownership of Occurrence Data as long as two conditions are met; that is, each subset of occurrence data is (1) distinguishable from other subsets - and the criteria are recorded, and (2) owned by only one owner at a time. For example: The Ministry of Interior and the Ministry of Justice are both Occurrence Data Owners for PERSON_FIRST_NAME, with the former owning names of Syrians and the latter owning names of Aliens. In this example, the following criteria to distinguish data subset ownership could be recorded: For Ministry of Interior: The respective CITIZENSHIP_COUNTRY_NAME attribute value must be equal to: Syria For Ministry of Justice: The respective CITIZENSHIP_COUNTRY_NAME attribute value must not be equal to: Syria SSADM ENGINEER: Record as a relationship, using Associations ⌫Project Records⌫General Forms menu options. Also, if more than Owners exist, record criteria used to distinguish each data subset on Description field of each Owner’s General Form. Form Type (Ref): OWN_OCC (Ownership Occurrence) Form Name: Occurrence Data Owner Authority

6.2.15 Access Rights (Mandatory)

a. Meta-data All systems (at least those that use the attribute - see section 6.2.2) will have read-only access to meta-data (subject to any attribute Security Level - see section 6.2.16), but no rights to modify it. In exceptional circumstances the Ownership Authority may delegate update rights to another Department or Ministry. All Meta-data access right holders, including the Ownership Authority must be recorded. SSADM ENGINEER: Record as a relationship, using Associations ⌫Project Records⌫General Forms menu options.

Form Type (Ref): MD_ACCES (Meta-Data Access)

Form Name: Meta Data Access Holder

b. Occurrence Data. All business areas/functions/individuals that require the occurrence data to carry out their work, will be authorized to use the data after they are granted access rights by the Occurrence Data Owner. Access rights must be defined along with type of use (read, create, update, delete), and any special restrictions/rules, e.g. ‘may not see salaries over Grade n’. A non-GDM attribute will have one access right holder, that being the Occurrence Data Owner in most cases. A GDM attribute will have more than access right holder. SSADM ENGINEER: Record as a relationship, using Associations ⌫Project Records⌫General Forms menu options. Also, record type of use (create, update, read and delete) and any special restrictions in the Description field of the general form.

Form Type (Ref): OC_ACCES (Occurrence Access)

Form Name: Occurrence Data Access Holder

6.2.16 Security Level (Optional)

Security classifications or grades define sets of rules, procedures, and restrictions that deal with attribute storage and/or access matters. Security classifications may be attached to the attribute at three levels.

a. Occurrence of the attribute. SSADM ENGINEER: Record as a relationship, using Associations ⌫Project Records⌫General Forms menu options. Also, record any implications or limitations in the Description field of the General Form.

Form Type (Ref): SEC_OCC (Security Occurrence) Form Name: Occurrence Security Grade

b. Definition of the attribute SSADM ENGINEER: Record as a relationship, using Associations ⌫Project Records⌫General Forms menu options. Also, record any implications or limitations in the Description field of the General Form.

Form Type (Ref): SEC_DEF (Security Definition) Form Name: Definition Security Grade

c. Existence of the attribute (In this case the attribute will not be defined in the Central Data Dictionary)

6.2.17 Retention Period (Optional)

The attribute occurrences may be subject to legal rules which cover the time those occurrences must be retained on a system. SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options. Also, record any retention period rules in the Description field of the General Form.

Form Type (Ref): RETAIN

Form Type (Ref): RETAIN Form Name: Retention Period

6.2.18 Administrative Information (Mandatory)

Six types of administrative information are attached to the attribute definition: � Status (Draft, Approved, Issued, Archived) � Version Number � Date Created (must be held by the system automatically) � Date of last Change (must be held by the system automatically) � User who created the definition (must be held by the system automatically) � User who made the last change (must be held by the system automatically) SSADM ENGINEER: Record using File⌫Save Version menu options.

6.3 Entities

6.3.1 Name (mandatory)

Provides an unambiguous method of referring to an entity. The name must conform to Data Naming Standard described in chapter 5. SSADM ENGINEER: Record in Name field

6.3.2 Description (mandatory)

A textual description of the entity which should be as concise as possible, but still leave a reader with no doubt as to what the entity is. SSADM ENGINEER: Record in Description field.

6.3.3 Usage (CDD: Mandatory, Project LDM: Inapplicable)

Identification of the information systems that use the entity. This includes systems at all stages of the systems development life-cycle, but not operation. SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options. Form Type (Ref): USAGE Form Name: System User

6.3.4 Attributes and Keys (Mandatory)

All attributes in the entity should be recorded and those that are keys (primary, and foreign at least) clearly identified. Single-row entities are not required to have primary keys. SSADM ENGINEER: Record keys using Attributes⌫Keys menu options. Also, record target entity of each foreign key using Relationship Form and Associations⌫Detail Entity Key menu options. Note: If you have recorded the Relationship Implementation property in section 6.5.5 Implementation, then the target entity of each foreign key has been recorded in the tool as well.

6.3.5 Synonyms (Optional)

An alternative name used by an information system(s) for the same entity (i.e. different name, same entity definition). Synonyms must conform to Data Naming Standard described in chapter 5. Also, more than one Synonyms may exist for an entity. SSADM ENGINEER: Record in Description field.

6.3.6 Attribute Optionality (Optional)

Identifies all attributes contained in the entity that their occurrence data are not mandatory. SSADM ENGINEER: Record using Attributes⌫Selection⌫Make Optional menu options.

6.3.7 Volumetrics (CDD:Optional, Project LDM:Mandatory)

For projects it will be necessary to record the number of occurrences of each entity, including averages, peaks and minimums. SSADM ENGINEER: Record using Window⌫Volumetrics menu options, and Volumes fields.

6.4 Domains

6.4.1 General

Domains are used in Logical Data Models to represent validation and formatting rules, permitted classes and ranges of values which are common to more than one attribute. For example ‘DATE’, which relates to many attribute definitions, is the most common domain. Often domains are represented by Class Words in attribute names. Domains will be defined in the Central Data Dictionary. It will be unusual but not unknown for a project to find it necessary to define a project-specific domain. Properties to be defined for each domain are listed next.

6.4.2 Name (Mandatory)

Provides an unambiguous method of referring to a domain. The name must conform to Data Naming Standard described in chapter 5. SSADM ENGINEER: Record in Name field.

6.4.3 Description (Mandatory)

A textual description of the domain. The description should be worded without assuming any prior knowledge of the reader. If the definition has been extracted from a formal source the description should read exactly as in the source. SSADM ENGINEER: Record in Description field.

6.4.4 Synonyms (Optional)

An alternative name used by an information system(s) for the same domain (i.e. different name, same domain definition). Synonyms must conform to Data Naming Standard described in chapter 5. Also, more than one Synonym may exist for a domain.

SSADM ENGINEER: Record in Description field.

6.4.5 Data Format and Length (Mandatory)

The format (i.e. data type) and length of the domain e.g. CHARACTER, 6, and whether it can be signed (positive only, or positive and negative) when relevant. Valid data types include:

CHARACTER (for alphabetic, numeric, special characters), DATE (for numeric characters), INTEGER (for numeric characters - integers), DECIMAL (for numeric characters - real numbers)

SSADM ENGINEER: Record in Description field.

6.4.6 Data Format Mask (Optional)

A format mask holds additional domain formatting information, such as character type and position, special characters used for presentation, and structure in the case of simple domains that are held in a structured format (see section 6.4.7) e.g. date domains. To express the format mask the following may be used:

X (for occurrence data made of Alphanumeric characters), A (for occurrence data made of Alphabetic characters), 9 (for occurrence data made of Numeric characters), Alphanumeric and special characters used mainly for presentation e.g. hyphen (-), credit symbol (CR), Examples, e.g. 25-05 11:55 (Day + Month + Hours + Minutes) to express the components of a domain that is held in a structured format The characters specified must be compatible with the Data Format specified in section 6.4.5. For instance, if Data Type is Integer, then Storage Mask cannot contain alphabetic symbols e.g. as in 99AAA99. There are two types of Data Format Masks: a. Storage Mask. For example: The attribute of CERTIFICATE_NUMBER may be stored in alphanumeric format. The storage mask shows which characters are alphabetic and which numeric (AA9999999). SSADM ENGINEER: Record in Description field. b. Presentation Mask. For example: A date may be presented (by output devices) with slashes in fixed places. A presentation format mask to express this is 99/AAA/9999. Alternatively, a date domain may be expressed as 25 Aug 1993; notice this mask defines the components of a simple domain that is held in a structured format, the components’ order, the character type and position, and the special characters used (i.e. the spaces). SSADM ENGINEER: Record in Description field.

6.4.7 Structured Domains (Optional)

When there is a number of structured attributes that have the same underlying structure (i.e. composed of the same simple attributes), a structured domain may be defined for them. For example, if we had the following structured attributes:

PERSON_BIRTH_CERTIFICATE_NO, PERSON_DEATH_CERTIFICATE_NO, MARRIAGE_CERTIFICATE_NO

A structured domain could be defined for them, such as:

CERT_ISSUE_DATE + CERT_TYPE_CODE + CERT_SERIAL_NO The first two parts are attributes in their own right used in other entities. In these cases the composition must be explained with reference to these attributes. The third attribute is not a separate attribute therefore its’ definition must be explained within the context of the Structured Domain. Generally structured domains are to be avoided unless there is a good business reason for using them.

6.4.8 Data Values and Ranges (Optional)

The discrete values a domain may take, or the possible ranges of values. SSADM ENGINEER: Record in Description field.

6.4.9 Validation (Optional)

Any validation rules related to the entry or updating of the values of the attribute(s) that inherit from the domain. The validation may be expressed by reference to other attributes. For example, a validation rule for a domain named ORGANISATION_LIFE_DATE could read as follows:

ORGANISATION_LIFE_DATE must be (equal to, or later than ORGANISATION_REGISTRATION_DATE) and (equal to, or earlier than ORGANISATION_REMOVAL_DATE) for the same ORGANISATION entity occurrence SSADM ENGINEER: Record as a relationship, using Associations⌫Modules ⌫Module Set menu options. A module set with the same name as the domain name must be defined first, using Module Sets Form.

6.4.10 Ownership (Mandatory)

Domain ownership relates to meta-data. The owner is the authority responsible for the decisions related to the definition of the domain. No other can change the definition. The owner may be a Government Ministry/Department or the Data Management Group. SSADM ENGINEER: Record as a relationship, using Associations⌫Project Records⌫General Forms menu options.

Form Type (Ref): OWN_AUTH (Ownership Authority) Form Name: Meta Data Owner Authority

6.4.11 Administrative Information (CDD:Mandatory, Project LDM:Optional)

Six types of administrative information are attached to the domain definition: � Status (Draft, Approved, Issued, Archived) � Version Number � Date Created (must be held by the system automatically) � Date of last Change (must be held by the system automatically) � User who created the definition (must be held by the system automatically) � User who made the last change (must be held by the system automatically) SSADM ENGINEER: Record using File⌫Save Version menu options.

6.5 Relationships

6.5.1 General

Relationships between Entities on a Logical Data Structure are represented in two directions, from Master to Detail and from Detail to Master. Each relationship must therefore have two descriptions. The Name and Description properties described next should be recorded for each relationship description, and the Volumetrics and Implementation properties should be recorded only once (for the Detail to Master description).

6.5.2 Name (Mandatory)

Provides an unambiguous method for identifying a relationship. The name must conform to Data Naming Standard described in chapter 5. SSADM ENGINEER: Record using Link Phrase field.

6.5.3 Description (Optional)

A textual description of the relationship which should be as concise as possible, but still leave a reader with no doubt as to what role the relationship represents. As a general guideline, Descriptions should be entered only when relationship names are inadequate in expressing the meaning of the business relationship between two entities.

SSADM ENGINEER: Record using Window⌫Master to Detail Description and Window⌫Detail to Master Description menu options.

6.5.4 Volumetrics (CDD:Optional, Project LDM:Mandatory)

The minimum and/or average and/or maximum number of detail entity occurrences expected for each master entity occurrence. SSADM ENGINEER: Record using Window⌫Detail to Master Volumetrics menu options.

6.5.5 Implementation (CDD:Mandatory, Project LDM:Optional)

The foreign key in the Detail Entity that is used to implement the relationship.

SSADM ENGINEER: Record using Associations⌫Detail Entity Key menu options. Note: If you have recorded target entities for foreign keys in the Detail Entity of this relationship in section 6.3.4 Attributes and Keys, then this property (Implementation) has been recorded in the tool as well.

APPENDICES

7 APPENDIX A: Suggested abbreviations and acronyms

Abbreviation / Acronym MeaningACC Account ADDR Address ADMIN Administration/Administrative/Administrator AMT Amount CERT Certificate COOP Co-operative DEPT Department DESC Description DIST District DOC Document FREQ Frequency ID Identification INFO Information INTL International MSR Measure NO Number OCC Occupation ORG Organisation PIN Personal Identification Number PREV Previous PROJ Project QTY Quantity REC Record REF Reference REP Report RES Residence SEQ Sequence STR Street SY Syria SYP Syrian Pounds TEL Telephone US United States VAT Value Added Tax YRS Years

8 APPENDIX B: Suggested Prime Words Prime WordADOPTION ALIEN APPLICANT APPLICATION AREA ARMY BUILDING CERTIFICATE CITIZENSHIP COMMUNITY CONTRACT COUNTRY COURT CURRENCY DEBT DEATH DEPENDENT DISTRICT DRIVER EDUCATION ELECTION EMPLOYEE EMPLOYMENT EMPLOYER INDUSTRY LAND LANGUAGE MARRIAGE MORTGAGE NATURALISATION OCCUPATION ORGANISATION PARISH PASSPORT PERSON PROPERTY REFUGEE REGION RELIGION RESIDENCE SHARE

SHAREHOLDER SHAREHOLDING SOCIETY STREET SYRIA SYRIAN TENANCY TENANT TOWN TRAVEL VEHICLE VILLAGE

9 APPENDIX C: Suggested Class Words Class Word MeaningCODE A key or a system utilised for identification (unique or not),

classification, or flagging (as an indicator) purposes. Usually used to represent another data element that exists in a different form such as Country Name, Sex Type Description, Currency Name. Made of numeric and/or alphabetic characters, and rarely of special characters. Examples:COUNTRY_CODE, PERSON_SEX_TYPE_CODE (e.g. M, F), CURRENCY_SYMBOL_CODE (e.g. £, $)

DATE A point in time, calendar or clock. May include day, month, year, hour, minute etc. Made of numeric characters. Examples:ORGANISATION_REGISTRATION_DATE, VEHICLE_LICENCE_RENEWAL_DATE, EMPLOYEE_WORK_ARRIVAL_TIME_DATE (e.g. 22/09/1995 07:35)

DESCRIPTION (DESC)

Used for explanation and description, or for remarks. Made of alphabetic and may be numeric characters. Examples:PROPERTY_DESCRIPTION (e.g. A field containing several trees, 1 CYTA pole, and a well), NATURALISATION_REMARKS_DESC

MEASURE (MSR) Used to express certain geometric values such as dimension e.g. length, distance e.g. miles, capacity/volume, speed, weight, percentage/rate, density, size, etc. Usually made of numeric characters. Examples:BUILDING_PERIMETER_FEET_MEASURE, AREA_DISTANCE_MILES_MEASURE, PERSON_HEIGHT_MEASURE, ORG_LIQUIDITY_PERCENT_MEASURE (e.g. .025)

NAME Used for identification (unique or not), or classification purposes. Usually made of alphabetic characters. Examples:CURRENCY_NAME (e.g. Syrian Pound), TRAVEL_DOCUMENT_TYPE_NAME (e.g. Passport, Group Pass)