Data Dictionary (DD) Template v4 - HUD



Data Dictionary (DD) Template Version 5.4 – 8/1/2008

A DD Template provides HUD a standard DD template for use in new database systems development. It provides a standard format for loading data element information into a future Metadata Repository (MDR). A DD template is required by the HUD System Development Methodology (SDM) as specified in the SDM Database Specifications Checklist document. This template defines the required format and contents for that DD requirement. It will be filled out in two phases, initially after the SDM Define System phase is completed and then it is completed after the SDM Build System phase. The “When Required” column identifies which DD template column should be completed during which phase.

This document describes the contents of the template; the actual template is an Excel spreadsheet which contains the following fields:

|Template Column |Description |Value |When Required |

| | |Restriction |(Define or Build) |

| | |(blank = none) | |

|HUD System Code |HUD IT system code. This identifies the system that the data element belongs to. | |Build |

|HUD System Name |HUD IT system name that identifies the system | |Build |

|HUD DRM Subject Area |The HUD DRM Subject Area that the data element maps to. HUD DRM Subject Areas are documented| |Define |

| |in the HUD Target EA Document, | | |

|HUD DRM Entity |The HUD DRM Entity that the data element maps to. HUD DRM Entities are documented in the HUD| |Define |

| |Target EA Document, | | |

|LDM Entity Name |Name of entity in the Logical Data Model (LDM) that the data element is stored in. | |Define |

|Data Element (DE) Name |The name of the data element or attribute as represented in the LDM. The most elementary | |Define |

| |unit of data that can be identified and described. | | |

|DE Description |The description of the data contained in the data element. | |Define |

|Physical Table Name |The name of the table in which the proposed physical data element will reside. | |Build |

|Physical Data Element Name |The name of the proposed physical data element. | |Build |

|Data Type |Database data element type, i.e. Integer, Char, DateTime. | |Define |

|Max Length |Maximum length of the data that can be stored in the data element. |Numeric value |Define |

|Precision (numeric) |Precision of numeric data element; the number of decimal places. |Numeric value |Build |

|Primary key? |Answers the question: Is this data element the primary or part of the primary key for the |Y or N |Define |

| |table that the data element is a part of? | | |

|Foreign key? |Answers the question: Is this data element a foreign or part of a foreign key for the table |Y or N |Define |

| |that the data element is a part of? | | |

|Listed or Enumerated Values |The valid values for this data element if the data element value is constrained. | |Define |

|Default Value |The default value for this data element if no value is entered at the time the record is | |Define |

| |created. | | |

|Required? |Answers the question: Is the data element required to contain data when the record is |Y or N |Define |

| |created? | | |

|Read-only? |Answers the question: Does this data element contain read only or static data? |Y or N |Define |

|Integrity Requirements |The dependence of the data element on the existence of another data element and, if so, what| |Define |

| |the requirements of the dependency are. | | |

|Format Requirements |Data format requirements (i.e., Social Security number must include dashes). | |Define |

|Security Classification |The security classification of the data element. | |Define |

|Business Rules |The constraints on the data element’s value based on a business requirement (e.g., a | |Define/Build |

| |purchase order number may not be created if the customer's credit rating is not adequate). | | |

|Data Source System |If this data element originates from another system, enter that system name, table name, and| |Define |

| |data element name in this field. | | |

|Data Source Requirement Reference |The form, law or act, HUD requirement that this data element meets or comes from, if | |Define |

| |applicable. Some possible examples are; Sponsor Address Street Name from HUD-40112 (form), | | |

| |or Section of Act 504 (2) (a), Education Institution Name (Congressional act), or Type of | | |

| |Assistance Transaction from the Federal Funding Accountability and Transparency Act | | |

|XML Tag |The XML tag for this data element if the data element is part of an XML document. | |Build |

|Logical Business English Name |The full business name used at HUD to identify this element and which corresponds to the | |Define |

| |data dictionary data element. | | |

|Data Steward Name |Name and email contact information for the data element owning HUD Data Steward. Contact the| |Build |

| |EA Team (ea.team.support@) for information about the current Data Stewards at HUD. | | |

Data Element Descriptions Guidance

Precise and unambiguous data definitions or description are one of the most critical aspects of ensuring data sharing. It is essential that there is explicit understanding regarding the meaning of data. One primary way for ensuring that the data’s meaning is clearly understood is by the data description. Therefore, it is required that every data element have a well-formed definition, one that is clearly understood by every user.

This section contains the guidelines for providing good data elements descriptions. This section is from guidance provided by the HUD, Office of the Chief Financial Officer (OCFO) in the document named, Data Element Naming Conventions and Guidelines, Version 2.3, September 2000.

1 Rules

A data definition shall:

* Be unique

* Be stated in the singular

* State what the concept is, not only what it is not

* Be stated as a descriptive phrase or sentence(s)

* Contain only commonly understood abbreviations

* Be expressed without embedding definitions of other data elements or underlying concepts

2 Guidelines

A data definition should:

* State the essential meaning of the concept

* Be precise and unambiguous

* Be concise

* Be able to stand alone

* Be expressed without embedding rationale, functional usage, domain information, or procedural information

* Avoid circular reasoning

* Use the same terminology and consistent logical structure for related definitions

Detailed description

To facilitate the understanding of the rules and the guidelines for the construction of well-formed data definitions, explanations and examples are provided below. Each rule and guideline is followed by a short explanation of its meaning. Examples are given to support the explanations. In all cases, a good example is provided to exemplify the explanation. When deemed beneficial, a poor, but commonly used, example is given to show how a definition should not be constructed. A statement of rationale follows the examples to further explain the differences between the two.

1 Rules

* A data definition shall be unique.

* EXPLANATION: Each definition shall be distinguishable from every other definition within the data dictionary in which it appears. This ensures that specificity is retained. One or several characteristics that are expressed in the definition must differentiate the concept to be defined from other concepts.

* EXAMPLE:

1. Good definitions:

“Goods Dispatch Date” - The date on which goods are dispatched by a given party.

“Goods Receipt Date” - The date on which goods are received by a given party.

2. Poor definitions:

“Goods Dispatch Date” - The date on which the goods are delivered.

“Goods Receipt Date” - The date on which the goods are delivered.

* REASON: The definition “The date on which the goods are delivered” cannot be used for both data elements “Goods Receipt Date” and “Goods Dispatch Date.” Instead, each definition must be different.

* A data definition shall be stated in the singular.

* EXPLANATION: The concept expressed by the data definition shall be expressed in the singular. An exception is made if the concept itself is plural.

* EXAMPLE:

1. Good definition:

“Article Number” - A reference number that identifies an article.

2. Poor definition:

“Article Number” - Reference number identifying articles.

* REASON: The poor definition uses the plural word “articles;” this is ambiguous because it could imply that an “article number” refers to more than one article.

* A data definition shall state what the concept is, not only what it is not.

* EXPLANATION: When constructing definitions, the concept cannot be defined exclusively by stating what the concept is not.

* EXAMPLE:

1. Good definition:

“Freight Cost Amount” - The cost amount that is incurred by a shipper when moving goods from one place to another.

2. Poor definition:

“Freight Cost Amount” - The costs that are not related to packing, documentation, loading, unloading, and insurance.

* REASON: The poor definition does not specify what is included in the meaning of the data.

* A data definition shall be stated as a descriptive phrase or sentence(s).

* EXPLANATION: A phrase is necessary to form a precise definition that includes the essential characteristics of the concept. Simply stating one or more synonym(s) is insufficient. Simply restating the words of the name in a different order is insufficient. If more than a descriptive phrase is needed, use complete, grammatically correct sentences.

* EXAMPLE:

1. Good definition:

“Agent Name” - The name of the party authorized to act on behalf of another party.

2. Poor definition:

“Agent Name” - Representative.

* REASON: “Representative” is a near-synonym of the data element name, which is not adequate for a definition.

* A data definition shall contain only commonly understood abbreviations.

* EXPLANATION: Understanding the meaning of an abbreviation, including acronyms and initialisms, is usually confined to a certain environment. In other environments, the same abbreviation can cause misinterpretation or confusion. Therefore, to avoid ambiguity, full words, not abbreviations, shall be used in the definition.

An exception to this rule may be made if an abbreviation is commonly understood, such as “i.e.” and “e.g.,” or if an abbreviation is more readily understood than the full form of the complex term and has been adopted as a term in its own right, such as “radar,” which stands for “radio detecting and ranging.”

All acronyms must be expanded on the first occurrence.

* EXAMPLE 1:

1. Good definition:

“Tide Height” - The vertical distance from mean sea level (MSL) to a specific tide level.

2. Poor definition:

“Tide Height” - The vertical distance from MSL to a specific tide level.

* REASON: The poor definition is unclear because the acronym MSL is not commonly understood; some users may need to refer to other sources to determine what it represents. Without the full word, finding the term in a glossary may be difficult or impossible.

* EXAMPLE 2:

1. Good definition:

“Unit of Density Measurement” - The unit employed when measuring the concentration of matter in terms of mass per unit (m.p.u.) volume, e.g., pound per cubic foot; kilogram per cubic meter.

2. Poor definition:

“Unit of Density Measurement” - The unit employed when measuring the concentration of matter in terms of m.p.u. volume, e.g., pound per cubic foot; kilogram per cubic meter.

* REASON: M.p.u. is not a common abbreviation and its meaning may not be understood by some users. The abbreviation should be expanded to full words.

* A data definition shall be expressed without embedding the definitions of other data elements or of underlying concepts.

* EXPLANATION: The definition of a second data element or of a related concept should not appear in the definition of the primary data element. Definitions of terms should be provided in an associated glossary. If the second definition is necessary, it may be attached by a note at the end of the primary definition’s main text or as a separate entry in the dictionary. Related definitions can be accessed through relational attributes, e.g., cross-reference.

* EXAMPLE 1:

1. Good definition:

“Sample Type Code” - The code that identifies the kind of sample.

2. Poor definition:

“Sample Type Code” - The code that identifies the kind of sample collected. A sample is a small specimen taken for testing. It can be either an actual sample for testing, or a quality control sample. A quality control sample is a surrogate sample taken to verify results of actual samples.

* REASON: The poor definition contains two extraneous definitions embedded within it. They are the definitions of “sample” and of “quality control sample.”

* EXAMPLE 2:

1. Good definition:

“Issuing Bank Documentary Credit Number” - The reference number that is assigned by the issuing bank to a documentary credit.

2. Poor definition:

“Issuing Bank Documentary Credit Number” - The reference number that is assigned by the issuing bank to a documentary credit. A documentary credit is a document in which a bank states that it has issued a documentary credit under which the beneficiary is to obtain payment, acceptance, or negotiation on compliance with certain terms and conditions and against presentation of stipulated documents and such drafts as may be specified.

* REASON: The poor definition contains a concept definition, which should be included in a glossary.

2 Guidelines

* A data definition should state the essential meaning of the concept.

* EXPLANATION: All primary characteristics of the concept that are represented should appear in the definition at the relevant level of specificity for the context. The inclusion of non-essential characteristics should be avoided. The level of detail necessary is dependent upon the needs of the system user and the environment.

* EXAMPLE 1: (Intended context: any form of transportation)

1. Good definition:

“Consignment Loading Sequence Number” - The number that indicates the sequence in which consignments are loaded onto a means of transport or piece of transport equipment.

2. Poor definition:

“Consignment Loading Sequence Number” - The number that indicates the sequence in which consignments are loaded onto a truck.

* REASON: In the intended context, consignments can be transported by various transportation modes, e.g., trucks, vessels, or freight trains. Consignments are not limited to trucks for transport.

* EXAMPLE 2:

1. Good definition:

“Invoice Amount” - The total sum that is charged on an invoice.

2. Poor definition:

“Invoice Amount” - The total sum of all chargeable items mentioned on an invoice, taking into account deductions on one hand, such as allowances and discounts, and additions on the other hand, such as charges for insurance, transport, handling, etc.

* REASON: The poor definition includes extraneous material.

* A data definition should be precise and unambiguous.

* EXPLANATION: The exact meaning and interpretation of the defined concept should be apparent from the definition. A definition should be clear enough to allow only one possible interpretation.

* EXAMPLE:

1. Good definition:

“Shipment Receipt Date” - The date upon which the shipment is received by the receiving party.

2. Poor definition:

“Shipment Receipt Date” - The date upon which the shipment is delivered.

* REASON: The poor definition does not specify what determines a “delivery.” “Delivery” could be understood as either the act of unloading a product at the intended destination or as the point at which the intended customer actually obtains the product. It is possible that the intended customer never receives the product that has been unloaded or that the customer may receive the product days after it was unloaded at the site.

* A data definition should be concise.

* EXPLANATION: The definition should be brief and comprehensive. Extraneous qualifying phrases such as “for the purpose of this data dictionary” or “terms to be described” shall be avoided.

* EXAMPLE:

1. Good definition:

“Character Set Name” - The name given to the set of phonetic or ideographic symbols in which data is encoded.

2. Poor definition:

“Character Set Name” - The name given to the set of phonetic or ideographic symbols in which data is encoded, for the purpose of this data dictionary, or, as used elsewhere, the capability of systems hardware and software to process data encoded in one or more scripts.

* REASON: In the poor definition, all of the phrases that follow “…data is encoded” are extraneous, qualifying phrases.

* A data definition should be able to stand alone.

* EXPLANATION: The meaning of the concept should be apparent from the definition. Additional explanations or references should not be necessary to understand the meaning of the definition.

* EXAMPLE:

1. Good definition:

“School Location City Name” - The name of the city where the school is situated.

2. Poor definition:

“School Location City Name” - See school site.

* REASON: The poor definition does not stand alone; it requires the aid of a second definition (school site) to understand the meaning of the first.

* A data definition should be expressed without embedding rationale, functional usage, domain information, or procedural information.

* EXPLANATION: Although they are often necessary, such statements do not belong in the definition because they contain information extraneous to the purpose of the definition. If deemed useful, such expressions may be placed in other data element attributes.

(1) The rationale for a given definition should not be included as part of the definition, e.g., if a data element uses miles instead of kilometers, the reason should not be indicated in the definition.

(2) Functional usage such as “this data element should not be used for…” should not be included in the definition.

(3) Remarks about procedural aspects, such as “this data element is used in conjunction with data element ‘xxx,’” should not appear in the definition; instead, use “related data reference” and “type of relationship.”

* EXAMPLE:

1. Good definition:

“Data Field Label” - The identification of a field in an index, thesaurus, query, database, etc.

2. Poor definition:

“Data Field Label” - The identification of a field in an index, thesaurus, query, database, etc., which is provided for units of information such as abstracts and columns within tables.

* REASON: The poor definition contains remarks about functional usage. The phrases starting with “which is provided for…” must be excluded from the definition and placed in another attribute, if it is necessary information.

* A data definition should avoid circular reasoning.

* EXPLANATION: Two definitions shall not be defined in terms of each other. A definition should not use another concept’s definition as its definition. This results in a situation where a concept is defined with the aid of another concept that is, in turn, defined with the aid of the given concept.

* EXAMPLE: (Two data elements with poor definitions.)

1. “Employee ID Number” - The number assigned to the employee.

2. “Employee Name” - The employee who has been assigned the employee ID number.

* REASON: Each definition refers to the other for its meaning. The meaning is not given in either definition.

* A data definition should use the same terminology and consistent logical structure for related definitions.

* EXPLANATION: A common terminology and syntax should be used for similar or associated definitions.

* EXAMPLE: (Two data elements with good definitions. Both definitions pertain to related concepts and, therefore, have the same logical structure and similar terminology.)

1. “Goods Dispatch Date” - The date on which the goods were dispatched by a

given party.

2. “Goods Receipt Date” - The date on which the goods were received by a

given party.

* REASON: Using the same terminology and syntax facilitates understanding. Otherwise, users wonder whether some difference is implied by the use of synonymous terms and variable syntax.

Data Dictionary Template Sample

The following is a sample utilizing this DD Template discussed above for the HUD National Housing Locator System (NHLS). The NHLS is a web-enabled system allowing HUD’s staff and partners to access rental housing databases for available temporary housing.

HUD System Code |HUD System Name |HUD DRM Subject Area |HUD DRM Entity |LDM Entity Name |Data Element (DE) Name |DE Description

(Part 1) |DE Description

(Part 2) |Physical Table Name |Physical Data Element Name |Data Type |Max Length |Precision (decimal places) |Primary key? Y/N |Foreign key? Y/N |Listed or Enumerated Values |Default Value |Required? |Read-only? |Integrity Requirements |Format Requirements |Security Classification |Business Rules

(Part One) |Business Rules

(Part Two) |Data Source System |Data Source Requirement Reference |XML Tag |Logical Business English Name |Data Steward Name | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property ID |Table’s primary key is an assigned unique identification. This is a required field. | |CASE_PROPERTY |PROPERTYID |Number |20 | |Y |N | | |Y |N | |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |N/A |Case Property ID |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property Type Text |Text that describes the property type. | |CASE_PROPERTY |PROPERTYTYPE |Varchar2 |100 | |N |N | | |Y |N | |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The 'type' variable in element |Case Property Type |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property Address Text |Street address of the property. | |CASE_PROPERTY |ADDRESS |Varchar2 |255 | |N |N | | |Y |N | |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The element |Case Address |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property City Name Text |City of the property. | |CASE_PROPERTY |CITY |Varchar2 |50 | |N |N | | |Y |N | |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The element |Case City Name |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property State Code |State of the property. | |CASE_PROPERTY |STATE |Varchar2 |5 | |N |N | | |Y |N | |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The element |Case Property State |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property Zip Code |ZIP Code of the property. | |CASE_PROPERTY |ZIP |Varchar2 |10 | |N |N | | |Y |N |N/A |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The element |Case Property ZIP Code |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property County Text |County of the property. | |CASE_PROPERTY |COUNTY |Varchar2 |100 | |N |N | | |Y |N |N/A |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |N/A |Case Property County |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property Country Code |Country of the property. | |CASE_PROPERTY |COUNTRY |Varchar2 |5 | |N |N | | |Y |N |N/A |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The element |Case Property Country |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property Phone Number |Phone number of the property. | |CASE_PROPERTY |PHONE |Varchar2 |30 | |N |N | | |Y |N |N/A |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The element |Case Property Phone Number |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Housing Project |Case Property |Case Property URL |URL of the property description website. | |CASE_PROPERTY |URL |Varchar2 |500 | |N |N | | |N |N |N/A |N/A |Sensitive |Data is acquired from the NHLS_PROPERTY table when the user adds properties to a citizen's case. |NHLS |Data obtain from the NHLS_PROPERTY table |The element |Case Property URL |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Identifier |Table’s primary key is an assigned unique identification. This is a required field. | |PHA_CONTACTS |CONTACTID |Number | | |Y |N | | |Y |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |N/A |PHA Contact Identifier |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact First Name Text |First name of the Public Housing Authority contact | |PHA_CONTACTS |FIRSTNAME |Varchar2 |50 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Exec Dir First Name |PHA Contact First Name |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Middle Name Text |Middle name of the Public Housing Authority contact | |PHA_CONTACTS |MIDDLENAME |Varchar2 |50 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |N/A |PHA Contact Middle Name |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Last Name Text |Last name of the Public Housing Authority contact | |PHA_CONTACTS |LASTNAME |Varchar2 |50 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Exec Dir Last Name |PHA Contact Last Name |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Address1 Text |First line of the Public Housing Authority's address | |PHA_CONTACTS |ADDRESS1 |Varchar2 |255 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Physical Address 1 |PHA Contact Address1 |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Address2 Text |Second line of the Public Housing Authority's address | |PHA_CONTACTS |ADDRESS2 |Varchar2 |255 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Physical Address 2 |PHA Contact Address2 |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact City Text |City of the Public Housing Authority's address | |PHA_CONTACTS |CITY |Varchar2 |50 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Physical City |PHA Contact City |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact State Code |State of the Public Housing Authority's address | |PHA_CONTACTS |STATE |Varchar2 |5 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Physical State Code |PHA Contact State |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Zip Code |ZIP code of the Public Housing Authority's address | |PHA_CONTACTS |ZIP |Varchar2 |10 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Physical Basic Zip;

Physical Zip Extension |PHA Contact ZIP Code |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Phone Number |Office phone number of the Public Housing Authority contact | |PHA_CONTACTS |PHONE |Varchar2 |30 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Phone |PHA Contact Phone Number |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Mobile Number |Mobile phone number of the Public Housing Authority contact | |PHA_CONTACTS |MOBILE |Varchar2 |30 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |N/A |PHA Contact Mobile Number |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Fax Number |Fax number of the Public Housing Authority contact | |PHA_CONTACTS |FAX |Varchar2 |30 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Fax |PHA Contact FAX Number |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Title Text |Title of the Public Housing Authority contact | |PHA_CONTACTS |TITLE |Varchar2 |255 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |N/A |PHA Contact Title |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Agency Name Text |Formal Name assigned to the Public Housing Authority | |PHA_CONTACTS |AGENCY |Varchar2 |255 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Formal HA Name |PHA Contact Agency |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Latitude |Float value of the latitudinal coordinate in degrees. | |PHA_CONTACTS |LATITUDE |Float | | |N |N | | |N |N |N/A |N/A |Public |Data must be a valid latitudinal reference based on the contact address obtained from HUD Geocoding processing. |PIH |Data obatined from HUD Geocoding service based on address from the PIH PIC sytem. |N/A |PHA Contact Latitude |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Longitude |Float value of the longitudinal coordinate in degrees. | |PHA_CONTACTS |LONGITUDE |Float | | |N |N | | |N |N |N/A |N/A |Public |Data must be a valid latitudinal reference based on the contact address obtained from HUD Geocoding processing. |PIH |Data obatined from HUD Geocoding service based on address from the PIH PIC sytem. |N/A |PHA Contact Longitude |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Region Text |Region of the Public Housing Authority contact | |PHA_CONTACTS |REGION |Varchar2 |100 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Region Code |PHA Contact Region |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Email Text |E-mail address of the Public Housing Authority contact | |PHA_CONTACTS |EMAIL |Varchar2 |100 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |Email Address |PHA Contact Email |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact PHA Code |HUD housing authority code issued to the Public Housing Authority | |PHA_CONTACTS |HACODE |Varchar2 |10 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |HA Code |PHA Contact PHA Code |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact Type Text |Type of Public Housing Authority | |PHA_CONTACTS |TYPE |Varchar2 |20 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |N/A |PHA Contact Type |PIH, Dallas Blair | |P254 |NHLS |Rental Assistance |Public Housing Agency |PHA Contacts |PHA Contact County Name Text |County of the Public Housing Authority’s address | |PHA_CONTACTS |COUNTY |Varchar2 |100 | |N |N | | |N |N |N/A |N/A |Public |Data must be current data from the PIH system. Non current data will be updated or removed. |PIH |Data obatined from the PIH PIC system. |N/A |PHA Contact County |PIH, Dallas Blair | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download