FLORIDA DEPARTMENT OF AGRICULTURE AND CONSUMER SERVICES
APPLICATION DEVELOPMENT STANDARDS AND GUIDELINES
VERSION 8.5
Creation Date: 04/21/2000 Last Updated: 07/12/2017
Application Development Standards
TABLE OF CONTENTS ECTION 1: PURPOSE ...... - 4 - SECTION 2: SCOPE ...... - 4 - SECTION 3: CHANGE PROCEDURES FOR THE APPLICATION DEVELOPMENT STANDARDS ...... - 5 - SECTION 4: SECURITY ...... - 5 - SECTION 4.1: NETWORK USER ACCOUNT ACCESS TYPES ...... - 6 - SECTION 4.2: ORACLE DATABASE LOGINS AND SECURITY ...... - 7 - SECTION 4.3: MICROSOFT ACCESS SECURITY ...... - 12 - SECTION 4.5: PASSWORDS ...... - 13 - SECTION 5: 60-8.001 FLORIDA ACCESSIBLE AND ELECTRONIC INFORMATION TECHNOLOGY RULE ...... - 14 - SECTION 5.1: TECHNICIAL STANDARDS ...... - 14 - SECTION 5.2: INFORMATION, DOCUMENTATION, AND SUPPORT ...... - 16 - SECTION 5.3: PROCUREMENT AND DEVELOPMENT CRITERIA ...... - 16 - SECTION 6: PUBLIC RECORDS & ELECTRONIC RECORDKEEPING REQUIREMENTS - 17 - SECTION 6.1: SOCIAL SECURITY NUMBERS ...... - 17 - SECTION 6.2 APPLICABILITY ...... - 17 - SECTION 6.3: CHAPTERS 1B-24 AND 1B-26.003, FLORIDA ADMINISTRATIVE CODE...... - 17 - SECTION 7: DATA INTEGRITY...... - 19 - SECTION 8: FDACS ENTERPRISE SYSTEMS AND DATA ...... - 20 - SECTION 8.1: ENTERPRISE SYSTEMS ...... - 20 - SECTION 8.2: EMPLOYEE DATA ...... - 22 - SECTION 8.3: EXTERNAL USERS ...... - 25 - SECTION 8.4: EMPLOYEE OBJECTS...... - 25 - SECTION 8.5: LOOK-UP TABLE ...... - 26 - SECTION 8.6: ABBREVIATIONS AND ACRONYMS...... - 26 - SECTION 9: ENTITY RELATIONSHIP DIAGRAM (E/R)GUIDELINES ...... - 27 - SECTION 9.1: ENTITY ...... - 27 - SECTION 9.2: ATTRIBUTE GUIDELINES ...... - 27 - SECTION 9.3: PRIMARY UNIQUE IDENTIFIER ATTRIBUTES ...... - 27 - SECTION 9.4: RELATIONSHIPS ...... - 28 - SECTION 10: AUDITING ...... - 29 - SECTION 10.1 AUDIT COLUMN ...... - 29 - SECTION 10.2 HISTORY TABLES ...... - 29 - SECTION 11: MISCELLANEOUS ORACLE REQUIREMENTS ...... - 30 - SECTION 12: GUIDELINES FOR NAMING DATABASE OBJECTS ...... - 32 - SECTION 12.1: GUIDELINES FOR TABLE NAMES ...... - 32 - SECTION 12.2: GUIDELINES FOR COLUMN/FIELD NAMES ...... - 32 - SECTION 12.3: TABLE VIEWS AND TABLE SYNONYMS ...... - 33 - SECTION 12.4: PRIMARY AND FOREIGN KEY COLUMNS...... - 33 - SECTION 12.5: CONSTRAINTS ...... - 34 - SECTION 12.6: PACKAGES, PROCEDURES, TRIGGERS, ETC...... - 35 - SECTION 13: DATABASE LINKS...... - 36 - SECTION 14: INDEXES ...... - 36 -
Page - 2 - of 113 Application Development Standards SECTION 15: FILE NAMES ...... - 37 - SECTION 16: TABLESPACES ...... - 37 - SECTION 17: TNSNAMES.ORA FILE ...... - 39 - APPENDIX 1: STANDARD DATA ELEMENTS ...... - 40 - APPENDIX 2: LOCATIONAL DATA STANDARDS ...... - 44 - APPENDIX 3: ENTITIES ...... - 58 - APPENDIX 4: ACRONYMS AND ABBREVIATIONS ...... - 65 - APPENDIX 5: EXAMPLE RELATIONSHIP NAME PAIRS ...... - 104 - APPENDIX 6: ORACLE APPLICATION SERVER STANDARDS ...... - 105 - APPENDIX 7 - FONTS AND PRINTING IN ORACLE REPORTS ...... - 108 - APPENDIX 8: .NET APPLICATION STANDARDS ...... - 110 -
Page - 3 - of 113 Application Development Standards
SECTION 1: PURPOSE
This document should be used in conjunction with the Administrative Policy and Procedure 1-2 – Information Technology Life Cycle (ITLC). The ITLC policy contains references to other Administrative Policies and Procedures, Florida Statutes and Florida Administrative Code governing public records requests, electronic records management, application development, and security that must be adhered to when developing or enhancing information systems.
Review of the most current version of this document should occur during the Needs Assessment Phase of the ITLC. You will find it most beneficial to read through this entire document to avoid having to make changes later in the application development process.
The purpose of this document is to provide a common basis for analysis and development of business systems at the Florida Department of Agriculture and Consumer Services (FDACS) using relational databases. The standards and conventions established by this document are intended to assist in the integration of applications across all business areas within the department. It is expected that the standards contained herein will continue to evolve to support the changing needs of FDACS. The standards have been reviewed and accepted by the Operational Steering Committee. The department has adopted separate Internet and Intranet Web Standards (June 23, 2005) and all department web sites must be Section 508, subsection 1194.22 compliant.
Oracle and SQL Server are the FDACS standard for relational database management systems. Custom applications and COTS applications must be compatible with the department’s existing database versions and configurations. They must also be compatible with the current Microsoft Windows and UNIX operating systems versions and configurations.
SECTION 2: SCOPE
This document applies to all custom application development efforts done in-house or by outside consultants/contractors developed for FDACS. If the application/database meets any of the following criteria, you should be following these standards.
Data that will be shared: data that is received from others, provided to others, or for which there are other stakeholders (such as local governments or private sector collaboration). Data involved in inter or intra-agency efforts: community data, created or used by multiple organizations, or divisions within FDACS. Public data: data that is accessible to the public. Data for current systems development or integration projects: to realize internal data integrity improvements for projects currently underway. Data involved in current modeling efforts: Data naming standards should be developed for the naming of entities, relationships, and attributes on object and data models. Without good naming standards on models, it will be difficult to transform model information to real data and be difficult to integrate models or share data.
Page - 4 - of 113 Application Development Standards
SECTION 3: CHANGE PROCEDURES FOR THE APPLICATION DEVELOPMENT STANDARDS
The documents will be maintained on a shared drive at tlhadmfilesrv02\THADAG_Share\APPLDEV\Application Standards and the OATS Intranet page. Any changes (additions, updates, deletions) to the appendices should be submitted to the data administrator for review. The data administrator will be responsible for keeping the documents updated. Changes to the Application Development Standards and Guidelines should be submitted to the data administrator for coordination and review with the ITLC/Data Administration Subcommittee of the Operational Steering Committee. The data administrator will be responsible for keeping the documents updated. All division information officers (DIO) will be informed of changes when they occur.
SECTION 4: SECURITY
SECURITY STANDARDS for NETWORK and APPLICATION AUTHENTICATION from Administrative Policy and Procedure 8-14 – Systems and Application Security Planning
Application security must follow Administrative Policy and Procedures Chapter 8 (Department Information Resource Security Program and Policies). If an alternative access, authentication, or security method is proposed, it shall be provided to and approved by the department Information Security Manager, in conjunction with designated OATS staff, prior to any programming work commencing.
Divisions must submit the proposed network and application security method to be used in the application when known, but no later than completion of the ITLC design process for the project. The proposed security method must be verified and approved by the department Information Security Manager before programming/coding begins. This document must include diagrams which designate the security method to be implemented. Adhering to this standard can avoid costly re-programming later.
Any exceptions to the policy should be documented in the final version of the Security Plan prior to production implementation and approved by the Information Security Manager.
Administrative Policy and Procedure 8-10, Section V, states the following: “The application owner, or his/her designee, is responsible for periodic monitoring (quarterly, semi-annual, or minimum annually) of user accounts for his/her applications. The designee should not be involved in development, maintenance, or custodial activities for the application. Monitoring is required to ensure the user is still employed with the department, and the user’s access privileges are based on the user’s current duties and responsibilities. The monitoring activities must be documented to satisfy auditing requirements and must be able to be provided on request.”
To ensure the application owner can comply with the policy, all new applications developed in- house or by a vendor, regardless of software environment (Oracle Developer, SQL Server, .Net Framework, MS Access, etc.) must provide to the application owner, or their designee, the ability to run a report at any time that provides at a minimum, the following information:
Page - 5 - of 113 Application Development Standards User account (e.g. pricep); User Name (e.g. Joe Smith); Application Role assigned to user (e.g. DISI_ADMIN); Application Roles and their privileges (what access level: insert, update, delete, select) granted to the application tables, views by the role; If access is not provided by a role, individual privileges granted to users or to the folder location of the application must be provided to the owner.
As a reminder, network and application accounts shall be created with the security principle of least privilege in mind. This principle means giving a user account only those privileges/access which are essential to that user being able to carry out their job functions, therefore ensuring account privileges be kept at a minimum at all times. Additionally, separation of duties is a fundamental element of account access control. No single user should have complete control of a function from beginning to end. This is to avoid any one user from knowingly, or unknowingly, subverting or damaging information resources.
Divisions must report all purchases of SSL certificates to the department Web Manager who will maintain a listing of servers where SSL certificates are installed.
SECTION 4.1: NETWORK USER ACCOUNT ACCESS TYPES
1. Department employees must authenticate against the Windows DOACS Domain, currently utilizing Active Directory. This can be accomplished by:
a. Direct infrastructure connection. An example of this would be a user on a Local Area Network (LAN) at an office connected to the state’s RTS Wide Area Network (WAN). b. Virtual Private Network (VPN) - Internet Protocol Security (IPsec) based VPN. Requires specialized software on the workstation and VPN approval form for access. c. Remote Access Services (RAS) – Dial up connectivity to the department network, through the department Remote Access Server. d. Web (SSL) VPN – access is to be limited to specific web applications which may require access to internal network resources. No software other than a compatible web browser is required, but approval for VPN access still needs to be authorized. Currently the capacity for concurrent users for this method is limited by infrastructure constraints.
2. Contractors / Consultants, OPS Employees, and Partners (example: verified external users with cooperative agreements, e.g. veterinarians trained to conduct data entry for Animal Industry applications) – This class of users will be issued an Active Directory Domain account through the department approved access process. The need for user access will be evaluated on an individual basis and security requirements for these accounts must meet or exceed those of regular department employees. It is the responsibility of the project manager responsible for managing the contractor/consultant and/or partner to submit the necessary request for initial access, as well as the revocation of access once the contractor/consultant no longer needs access. It is the responsibility of the OPS employee’s supervisor to submit the request for access and revocation of access upon termination. These accounts will be set to expire every ninety (90) days if there is no account activity (idle) unless justification not to expire the accounts is documented and approved by the Information Security Manager.
3. Unverified External Web Users (e.g., general public, permit holders, producers, no- solicitation registrants) – This class of users will not be provided domain accounts under any circumstances; accounts will be provided by web applications through application level
Page - 6 - of 113 Application Development Standards security. Access to applications will be provided via secure certificates, on a basis determined by the data being entered. If the data being entered is determined to meet privacy criteria (example: driver’s license number, birth dates, etc.), then a secure certificate is required for the web application. Database security will be handled as described in the sections below. Divisions should report all purchases of SSL certificates to the department Web Manager who will maintain a listing of servers where SSL certificates are installed. At a minimum, passwords must be set to expire every ninety (90) days unless justification not to expire the passwords is documented and approved by the Information Security Manager. Each application owner is responsible for orphaned accounts and management of user IDs and passwords.
4. Passwords for network accounts must meet the following criteria:
a. Passwords must expire at least every ninety (90) consecutive days. b. Password must be at least eight (8) characters. c. Password must contain at least three of the following four criteria: uppercase letter ((English A-Z), lowercase letter (English a-z), special character, one digit (base 10 digits 0-9). d. Password must not be the same or similar as the user-id. e. Password must be different from the previous five passwords (5) used. f. If an invalid password is entered, the system will re-query for a valid entry. g. The password must be stored in encrypted form. h. After five (5) consecutive login attempts, the account must lock for a period of not less than fifteen (15) minutes. i. User sessions must time-out after sixty (60) minutes of inactivity. User authentication shall be requested to proceed with usage of the system.
SECTION 4.2: ORACLE DATABASE LOGINS AND SECURITY
Internal Access
1. All internal users will authenticate against the Windows DOACS Domain (Active Directory). After authenticating to Active Directory, the possible methods for internal users to access the Oracle database(s) are:
a. Application captures Windows credentials Active Directory takes care of password requirements. Application uses Active Directory account to associate users to roles in application database tables. Application owner must approve application users and manage orphaned accounts (accounts for users who no longer have approved access). The application connects to Oracle with department-approved dedicated application user-id (DAU). The DAU and password are stored in encrypted format in a secure file on the web server to which only the application code, the server administrator and database administrator have access. A department-approved tool must be used to encrypt the connection string. The application populates the audit fields (CRE_USER and MOD_USER) with the Active Directory (Network) user-id; or the DAU may be used provided it is linked back to the unique Active Directory (Network) user-id through table relationships, maintained by referential integrity. The application must provide the ability to run a report detailing user privileges to the application for user account review by the application owner.
Page - 7 - of 113 Application Development Standards b. Application requires additional authentication with application-maintained credentials. (Example: web map service.) Application owner must approve application users and manage orphaned accounts (accounts for users who no longer have approved access). Application maintains list of unique application user-id’s and passwords in an application table. Application is responsible for implementing password requirements according to Administrative Policy and Procedure 8-10 (see “2. Passwords” below). Application connects to Oracle with a dedicated application user-id (DAU). The DAU and password are stored in a secure file on the web server to which only the application code, the server administrator, and database administrator have access. A department-approved tool must be used to encrypt the connection string. The application populates the CRE_USER and MOD_USER fields with the unique application user-id; or the DAU may be used provided it is linked back to the unique application user-id through table relationships, maintained by referential integrity. The application must provide the ability to run a report detailing user privileges to the application for user account review by the application owner.
c. Application requires additional authentication with a unique Oracle account and password. Oracle will enforce the password requirements. Oracle passwords will not be stored by the application. The application must handle Oracle expiration messages and provide a way for the user to change their password. The application populates the CRE_USER and MOD_USER fields with the unique Oracle user-id. d. Authenticate to Application through Oracle Application Server (AS) May use a unique Oracle user-id and password, or may use a dedicated application user-id (DAU) stored in the Oracle Database Access Descriptor (DAD). If using a unique Oracle user-id, Oracle will enforce the password requirements according to Administrative Policy and Procedure 8-10 (see “2. Passwords” below). The application populates the CRE_USER and MOD_USER fields with the unique Oracle user-id; or the DAU may be used provided it is linked back to the unique application user-id through table relationships, maintained by referential integrity. AS handles Oracle expiration messages and provides a way for the users to change their password. (Example: AIMS)
2. Passwords - Users who will be inserting, updating and deleting records must have individual logins to the database or to the application. This aids in auditing procedures on the tables and database security. The database enforces the following security requirements for individual logins; if user authentication (username/password) is being processed at the application level, rather than the database level, the application must include functionality to enforce these requirements (Please note: Oracle has slightly different requirements that Microsoft):
a. Passwords must expire at least every ninety (90) consecutive days. b. Password must be at least eight (8) characters. c. Password must start with a letter. d. Password must contain at least one letter (Oracle passwords are not case sensitive) one digit (base 10 digits 0-9), and one special character consisting of only the following : ~ ` ! ^ * ( ) _ - = [ ] { } | : ; < > ? , .
Page - 8 - of 113 Application Development Standards e. Password must not be the same or similar as the user-id. f. Password must be different from the previous five passwords (5) used. g. If an invalid password is entered, the system will re-query for a valid entry. h. The password must be stored in encrypted form. i. After five (5) consecutive login attempts, the account must lock for a period of not less than fifteen (15) minutes. j. User sessions must time-out after sixty (60) minutes of inactivity. User authentication shall be requested to proceed with usage of the system. k. Password cannot be reused for thirty (30) days.
External Access
1. The methods for external users (General Public) to access the Oracle database(s) are:
a. Using Microsoft Internet Information Services (IIS) (Example: Enterprise E- Commerce) Application resides on a web server in the DMZ. Access to the database goes through Oracle Connection Manager. Application connects to Oracle with a dedicated application user-id (DAU). The DAU and password are stored in a secure file on the web server to which only the application code, the server administrator, and the database administrator have access. Application provides web-based user a method to register for an application account. User receives email verification of account and password. At a minimum, passwords should be set to expire every ninety (90) days unless justification not to expire the passwords is documented and approved by the department Information Security Manager. Changes to production data must be processed through a “queue” (database table) for review by program area staff before update to production program tables occurs. If a different process for external production updates must occur, justification for the process must be documented and approved by the Information Security Manager. CRE_USER and MOD_USER fields will be populated with the unique application user-id; or with the DAU provided it is linked back to the unique web-based application user-id through table relationships, maintained by referential integrity.
b. Using Oracle Application Server (AS) (Example: AES Continuing Education Units) Application resides on a web server in the DMZ. Access to the database goes through Oracle Connection Manager. Application connects to Oracle with a dedicated application user-id (DAU). The DAU and password are stored in an Oracle DAD on the web server to which only the database administrator has access. Application provides web-based user a method to register for an application account. User receives email verification of account and password. At a minimum, passwords should be set to expire every ninety (90) days unless justification not to expire the passwords is documented and approved by the Information Security Manager. Changes to production data must be processed through a “queue” (database table) for review by program area staff before update to production program tables occurs. If a different process for external production updates must occur, justification for the process must be documented and approved by the department Information Security Manager.
Page - 9 - of 113 Application Development Standards CRE_USER and MOD_USER fields will be populated with the unique application user-id; or with the DAU provided it is linked back to the unique web-based application user-id through table relationships, maintained by referential integrity.
SECTION 4.3: SQL SERVER DATABASE LOGINS AND SECURITY
Internal Access
1. All internal users will authenticate against the Windows DOACS Domain (Active Directory). After authenticating to Active Directory, the possible methods for internal users to access the SQL Server database(s) are:
a. Application captures Windows credentials. Active Directory takes care of password requirements. Application uses Active Directory account to associate users to roles and privileges stored within the application. This can be based on the individual user or user’s membership in an Active Directory security group. Application owner must approve application users and manage orphaned accounts (accounts for users who no longer have approved access). The application connects to the database with a dedicated application user-id (DAU). The DAU and password are stored in encrypted format in a secure file on the web server to which only the application code, the server administrator and database administrator have access. A department-approved tool must be used to encrypt the connection string. The application populates the audit fields (CRE_USER and MOD_USER) with the Active Directory (Network) user-id; or the DAU may be used provided it is linked back to the unique Active Directory (Network) user-id through table relationships, maintained by referential integrity. The application must provide the ability to run a report detailing user privileges to the application for user account review by the application owner.
b. Application requires additional authentication. (Example: web map service.) The application presents a login window; the user authenticates with a unique application user-id and password. The application handles creating and maintaining unique user-id’s and passwords, which are stored in an application table; the password must be stored in an encrypted format. The application must implement and maintain password requirements according to Administrative Policy and Procedure 8-10 (see “2. Passwords” below). The application owner must approve application users and manage orphaned accounts (accounts for users who no longer have approved access). The application connects to the database with a dedicated application user-id (DAU). The DAU and password are stored in a secure file on the web server to which only the application code, the server administrator, and the database administrator have access. A department-approved tool must be used to encrypt the connection string. The application populates the audit fields (CRE_USER and MOD_USER) with the unique application user-id; or the DAU may be used provided it is linked back to the unique application user-id through table relationships, maintained by referential integrity. The application must provide the ability to run a report detailing user privileges to the application for user account review by the application owner.
Page - 10 - of 113 Application Development Standards c. For the development SQL Server(s) only: Active Directory domain groups will be created as needed based on divisions or specific applications. Developers’ unique Active Directory domain accounts will be added to the appropriate group(s). A SQL Server database user will be created for each Active Directory group. Developers will be able to access the SQL Server using SQL Server management Studio (SSMS) console or an ODBC connection setup on their workstation. Developers will be required to enter their Active Directory login and password each time they access the SQL Server.
2. Passwords - Users who will be inserting, updating and deleting records must have individual logins to the application. This aids in auditing procedures on the tables and database security. Active Directory enforces the following security requirements for individual logins; if user authentication (username/password) is being processed at the application level, rather than the Active Directory level, the application must include functionality to enforce these requirements:
a. Passwords must expire at least every ninety (90) consecutive days. b. Password must be at least eight (8) characters. c. Password must contain at least three of the following four criteria: uppercase letter ((English A-Z), lowercase letter (English a-z), special character, one digit (base 10 digits 0-9). d. Password must not be the same or similar as the user-id. e. Password must be different from the previous five passwords (5) used. f. If an invalid password is entered, the system will re-query for a valid entry. g. The password must be stored in encrypted form. h. After five (5) consecutive login attempts, the account must lock for a period of not less than fifteen (15) minutes. i. User sessions must time-out after sixty (60) minutes of inactivity. User authentication shall be requested to proceed with usage of the system.
External Access
1. The method for external users (general public) to access the SQL Server database(s) is Microsoft Internet Information Services (IIS). (Example: Food, Nutrition, and Wellness CNP application)
a. Application resides on a web server in the DMZ. b. Application connects to the database with a dedicated application user-id (DAU). The DAU and password are stored in a secure file on the web server to which only the application code, the server administrator, and the database administrator have access. c. Application provides web-based user a method to register for an application account. d. User receives email verification of account and password. e. At a minimum, passwords should be set to expire every ninety (90) days unless justification not to expire the passwords is documented and approved by the Information Security Manager. f. Changes to production data must be processed through a “queue” (database table) for review by program area staff before update to production program tables occurs. If a different process for external production updates must occur, justification for the process must be documented and approved by the department Information Security Manager. g. The application populates the audit fields (CRE_USER and MOD_USER) with the unique application user-id; or with the DAU provided it is linked back to the unique web- based application user-id through table relationships, maintained by referential integrity.
Page - 11 - of 113 Application Development Standards h. The application must provide the ability to run a report detailing user privileges to the application for user account review by the application owner
SECTION 4.4: MICROSOFT ACCESS SECURITY
Internal Access (Intranet and Internal Network Drive)
The recommended back-end databases for applications with multiple users storing sensitive or mission critical information are Oracle and SQL Server.
There are three levels of protection when considering options for securing Microsoft Access databases at design time:
1. Create a user password for those who will access the database. This method only secures the Microsoft Access application as a whole. It does not protect individual databases files. As such, this is not a viable option unless the database can only be opened from the server that houses it and all users of that server are forced to enter a password each time they start Microsoft Access. 2. Create a password for the database. This method helps protect data by only allowing users with these credentials to access the data inside the database. Unfortunately, this option is not 100% secure as there are several tools available for download that will discover both file-level passwords and user-level passwords. 3. Add the database to a specific workgroup. This method ensures that only computers that are a part of the workgroup may access the database, regardless of whether or not they have the correct login information. If the server which hosts the application needs to interact with databases that are not a part of the workgroup then this method cannot be used.
The best possible mix of protection for using MS Access databases is to: a. Force all users to log into MS Access individually. b. Set passwords on each MS Access database file. c. Create an isolated workgroup for the hosting server that is not shared among remote workstations.
Intranet Access
1. Intranet read only – the owner of the database is the one editing the database directly then replacing the database file on the intranet.
2. Intranet read/write – the Microsoft Access database is modified by an ASP script or a .Net application and may show specific text within the database on a web page. (Examples: sign- up applications, forum applications, FAQ applications).
External Access
Microsoft Access is not allowed for any new external facing application after the release of Version 8 of the Application Development Standards. The recommended back-end databases for Internet applications are SQL Server and Oracle.
1. Legacy Microsoft Access databases interacting with a .NET application using the .NET 2.0 or above Framework, must reside within the App_Data folder. This folder is not accessible via the Internet if the website is properly configured to use the .NET 2.0 or above Framework. 2. Legacy Microsoft Access databases interacting with Classic ASP or .NET 1.0 application must reside outside of the web site root directory.
Page - 12 - of 113 Application Development Standards
SECTION 4.5: GEOGRAPHIC INFORMATION SYSTEM SECURITY
Internal
a. Access may be direct (using desktop tools such as ESRI ArcCatalog, ArcMap, Google Maps, etc.), or through a department-approved map service or application. b. For direct access, users will connect with their unique Oracle user-id. c. Oracle accounts must be approved by the OATS GIS data administrator. d. Map services will use a dedicated application user-rid (DAU); the connection string must be stored encrypted in a file accessible only by the server administrator. e. For inserts/updates/deletes, the unique application user-id or unique Oracle user-id must be stored in the CRE_USER/MOD_USER fields. f. For production and control/beta/test environments, only the OATS GIS data administrator and delegates will have insert, update, or delete privileges; select privileges will be granted to appropriate viewer roles for each schema; these roles will be granted to appropriate division personnel. The OATS GIS data administrator may approve update privileges to an application (e.g. PEC). g. The division GIS data custodians will have insert/update/delete/select privileges on their division’s schemas in the development environment. h. Division GIS data custodians will notify the OATS GIS data administrator of the appropriate privileges required for GIS data in division specific schema of the Test and Production environments.
External
a. No direct access permitted; all access will be through department-approved map services or applications. b. Only read-only access is allowed. c. Map services will use a dedicated application user-id (DAU); the connection string must be stored encrypted in a file accessible only by the server administrator.
SECTION 4.6: PASSWORDS - General
In general, any users who will be inserting, updating and deleting records must have individual logins to the database or to the application. This includes commercial off-the-shelf applications and externally hosted applications, such as cloud-based solutions. This aids in auditing procedures and application security. If user authentication (username/password) is being processed at the application level, rather than the database level, the application must include functionality to enforce these requirements (please review the separate sections for Network, Oracle, SQL Server, Microsoft Access, and GIS for any specific password criteria required):
a. Passwords must expire at least every ninety (90) consecutive days. b. Password must be at least eight (8) characters. c. Password must contain at least three of the following four criteria: uppercase letter ((English A-Z), lowercase letter (English a-z), special character, one digit (base 10 digits 0-9). d. Password must not be the same or similar as the user-id. e. Password must be different from the previous five passwords (5) used. f. If an invalid password is entered, the system will re-query for a valid entry. g. The password must be stored in encrypted form. h. After five (5) consecutive login attempts, the account must lock for a period of not less than fifteen (15) minutes.
Page - 13 - of 113 Application Development Standards i. User sessions must time-out after sixty (60) minutes of inactivity. User authentication shall be requested to proceed with usage of the system.
If the application cannot meet all of the password requirements, and the Division assumes the risk, exceptions must have the approval of the department Information Security Manager prior to implementation/use. This should be documented in the Security Plan for the application.
SECTION 5: 60-8.0011 FLORIDA ACCESSIBLE AND ELECTRONIC INFORMATION TECHNOLOGY RULE
As of January 23, 2007, Chapter 60-8 was adopted to implement Sections 282.601-.606 Florida Statutes. The purpose of the Florida Accessible Electronic and Information Technology Rules is to promulgate rules for the development, procurement, maintenance and use of electronic information technology. The purpose and compliance with the rule is to ensure that individuals with disabilities have access to and use of information and data that is comparable to the access and use by members of the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency. “Compliance” also means compliance with the standards set forth in Rule 60-8.001, F.A.C., ensuring that state employees with disabilities have access to and are provided with information and data comparable to the access and use by state employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. These requirements should be considered starting at the Needs Assessment Phase of the ITLC so that redesign does not occur later in the application development process.
SECTION 5.1: TECHNICIAL STANDARDS
The list of standards below is taken directly from 60-8-1.002. It should be noted that our adopted Internet Web Standards (Internet and Intranet Web Standards) already incorporate many of the items on this list:
(1) The following technical standards shall be applicable to the development, procurement, maintenance and use of electronic and information technology: (a) Technical Standards 1. Software applications and operating systems.
i. When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. ii. Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. iii. A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes. iv. Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology.
Page - 14 - of 113 Application Development Standards When an image represents a program element, the information conveyed by the image must also be available in text. v. When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application’s performance. vi. Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes. vii. Application shall not override user selected contrast and color selections and other individual display attributes. viii. When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user. ix. Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. x. When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided. xi. Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. xii. When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
2. Web-based intranet and internet information and applications.
i. A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content). ii. Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. iii. Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. iv. Documents shall be organized so they are readable without requiring an associated style sheet. v. Redundant text links shall be provided for each active region of a server-side image map. vi. Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. vii. Row and column headers shall be identified for data tables. viii. Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. ix. Frames shall be titled with text that facilitates frame identification and navigation. x. Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. xi. A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. xii. When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. xiii. When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with rule sub-subparagraphs 60-8-1.002(1)(b)l.-16, F.A.C.
Page - 15 - of 113 Application Development Standards xiv. When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. xv. A method shall be provided that permits users to skip repetitive navigation links. xvi. When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
SECTION 5.2: INFORMATION, DOCUMENTATION, AND SUPPORT
Section 60-8.002(3) states the following: a. Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge. b. End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge. c. Support services for products shall accommodate the communication needs of end-users with disabilities. d. Nothing in this rule chapter shall be construed to require fundamental alteration in the nature of a product or its components. e. Products located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment are not required to comply with this rule chapter.
SECTION 5.3: PROCUREMENT AND DEVELOPMENT CRITERIA
1. Section 60-8.003, F.A.C. - Electronic and Information Technology Procurements section states that when procuring electronic and information technology resources, all effort shall be made to procure products which comply with the accessibility standards provided in Rule 60-8.002 F.A.C., when such products are available in the commercial marketplace or developed in response to a solicitation. The following language must be included in solicitations and contracts: Accessible Electronic Information Technology: Vendors submitting responses for this solicitation must provide electronic and information resources in complete compliance with the accessibility standards provided in Rule 60-8.002, F.A.C. (see Section 5.1). These standards establish a minimum level of accessibility.
2. Section 60-8.004, F.A.C. – Electronic and Information Technology Development section states that when designing, developing, and maintaining electronic and information technology resources, state agencies shall develop those processes or products which comply with the accessibility standards provided in Rule 60-8.002, F.A.C.(see Section 5.1).
3. Sections 60-8.003 and 1.004, F.A.C. – When procuring a product, or designing, developing and maintaining electronic and information technology resources, if a state agency determines that compliance with any provision of Sections 282.601 -.606, Florida Statutes, or this rule chapter imposes an undue burden, the documentation by the state agency supporting the procurement or determination of undue burden in design/development shall explain specifically why, and to what extent, compliance with each such provision creates an undue burden.
Page - 16 - of 113 Application Development Standards
SECTION 6: PUBLIC RECORDS & ELECTRONIC RECORDKEEPING REQUIREMENTS
SECTION 6.1: SOCIAL SECURITY NUMBERS
Section 119.071(5)(a)5, Florida Statutes, states that social security numbers held by an agency are confidential and exempt from s. 119.07(1) and s. 24(a), Article 1 of the State Constitution. Please refer to AP&P 1-9 – Public Records Inspection and/or Duplication Fees, which identifies other department information which is exempt from the provisions of Chapter 119, Florida Statutes.
Section 119.071(5)(a)2.a., Florida Statutes, states an agency may not collect an individual’s social security number unless the agency has stated in writing the purpose for its collection and unless it is: (I) Specifically authorized by law to do so; or (II)Imperative for the performance of that agency’s duties and responsibilities as prescribed by law. An agency collecting an individual’s social security number shall provide that individual with a copy of the written statement (s. 119.071(5)(a)3,F.S.).
SECTION 6.2: APPLICABILITY
Chapter 119.011(11), Florida Statutes concerning “public records” includes electronic records. Electronic records is any electronically recorded data which is (1) made or received pursuant to law or ordinance or in connection with the transaction of official business, or (2) any material prepared in connection with official agency business which is intended to perpetuate, communicate, or formalize knowledge of some type. Examples may include: 1. data files, 2. databases, 3. machine readable indexes, 4. word processing files, 5. electronic spreadsheets, 6. electronic mail and messages, 7. as well as other text or numeric information.
SECTION 6.3: CHAPTERS 1B-24 and 1B-26.003, FLORIDA ADMINISTRATIVE CODE
Chapter 1B-24, Florida Administrative Code is the Rule that outlines Public Records Scheduling and Disposition. Each division has a Records Management Liaison (RML) and in some divisions, each bureau has a RML (Department RML List). The RML should be contacted during the application requirements gathering to determine the “Records Retention Schedule” and, when possible, be made part of the application design. The department has two policies concerning Public Records and Records Management, AP&P 1-9 Public Records Inspection and/or Duplication Fees and AP&P 4-18 Records Management.
Chapter 1B-26.003 Florida Administrative Code is the Rule that outlines minimum requirements for the creation, utilization, maintenance, retention, preservation; storage and disposition of electronic record (master) copies, regardless of the media (Electronic Recordkeeping).
The Department of State has developed the State of Florida Electronic Records and Records Management Practices Handbook (DOS Electronic Records Handbook) to
Page - 17 - of 113 Application Development Standards assist State agencies in complying with all the Florida Statutes pertaining to records management. The handbook also lists questions that should be considered when the system is in development or system rewrite to address electronic records. The questions stated in the State of Florida Electronic Records and Records Management Practices are: 1. What is the system's purpose? Does it serve different purposes for different users'? Do the different purposes reflect different needs for retained data? 2. What inputs are needed and how long should they be retained? Are they needed for legal or audit purposes? 3. How long does information need to be kept online? Are online retention requirements directly indicated onto unit records or data sets? 4. If the agency no longer needs data online, does it need to retain it offline and for how long and in what format? 5. Can requirements for retention and disposition of data be integrated with system design and operations? For example: with update procedures, regular backup operations, creation of history files, subset files, and public use data sets? 6. What will be done with the reports, either on paper or computer output microfilm (COM), generated by the system? 7. Are multiple copies of the data needed? If so, in what format and media? In what locations? Do all media need to be maintained for the same length of time? What will happen to the different media, and when? How will the integrity and authority of the data be ensured'? 8. Is the information in the system part of the agency's vital records program? If so, what provisions must be made to ensure availability of the information in emergency situations. 9. Who is responsible for maintaining up-to-date, authoritative documentation of the system and the data it contains? Where will the documentation be maintained? 10. Which medium containing the data must be given special care to ensure data preservation for long term operational needs or for archival purposes?
The handbook (DOS Electronic Records Handbook) covers the following areas concerning electronic records and should be read in its entirety: 1. Recording requirements 2. Management roles and responsibilities 3. Organizing and controlling electronic records 4. Email as a public record 5. Maintenance and use of electronic records 6. Disposition of electronic records
These rules outline the documentation that must be kept pertaining to any electronic records system and must be able to be produced upon request from the public for information. These documents include:
1. A narrative description of the system, including all inputs and outputs of the system; the organization and contents of the files and records; policies on access and use; security controls; purpose and function of the system; update cycles or conditions and rules for adding information to the system, changing information in it, or deleting information; and the location and media in which electronic records are maintained and their retention requirements to ensure appropriate disposition of records in accordance with Chapter 1B-24, F.A.C.; 2. The physical and technical characteristics of the records, including a record layout or markup language that describes each file or field including the name, size, starting or relative position, and description of the form of the data (type such as alphabetic (character), decimal, or numeric) or a data dictionary or the equivalent information
Page - 18 - of 113 Application Development Standards associated with a database management system including a description of the relationship between data elements in databases; 3. For information coming from geographic information systems (GIS), the physical and technical characteristics of the records must be described including a data dictionary, a quality and accuracy report and a description of the graphic data structure; 4. Any other technical information needed to read or process the records. 5. Chapter 60-8 F.A.C.. Information, Documentation and Support for accessibility states the following: a. Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge. b. End-users shall have access to a description of the accessibility and compatibility features of products.
SECTION 7: DATA INTEGRITY
Every effort should be made to ensure the integrity and quality of data in the department. Data integrity is an umbrella term that refers to the consistency, accuracy and correctness of the data stored in a database. Think of data integrity in terms of the old adage: “garbage in- garbage out’”. Data integrity is about keeping the garbage out. The following guidelines should be followed.
1. There are four primary types of data integrity:
a. Entity Integrity – applies to the row level and ensures that each row in the table is uniquely identified to ensure a table does not have duplicate rows. Entity integrity ensures that each row has a unique identifier most often enforced by placing a primary key constraint on a specific column or a unique constraint (see next section for naming standards).The primary key constraint forces each value inserted into a column (or combination of columns) to be unique and will cause an insert to fail if a user attempts to insert a duplicate value into a column. i. A composite primary key is a primary key that consists of more than one column and it is used when none of the columns in the composite key is unique by itself. ii. Non-primary key columns on which uniqueness is enforced are referred to as alternate keys and are used as an “alternative” to the primary key for indexing or joining on. b. Domain integrity – is referred to as attribute integrity. It requires that a set of data values fall within a specific range (domain) in order to be valid and should be used whenever possible to aid in data quality and consistency. In other words, domain integrity defines the permissible entries for a given column by restricting the data type, format, or range of possible values (used as a drop down list). i. Examples of domain integrity would be to ensure an entry in an ‘age’ field is an integer and must be between the values of 0 and 120. ii. Domain integrity can be enforced with default constraint, foreign key, check constraint, data types, etc. For example:
CREATE TABLE employees (employee_id numeric(4), employee_name varchar2(50), employee_gender varchar2(1), CONSTRAINT employees_id_ck CHECK (employee_id BETWEEN 100 and 9999) CONSTRAINT employees_name_ck
Page - 19 - of 113 Application Development Standards CHECK (employee_name = upper(employee_name)) CONSTRAINT employees_gender_ck CHECK (employee_gender in ('F', 'M'));
c. Referential Integrity – occurs at the table level and means that the relationship between two tables must be preserved when records are inserted, updated and deleted. The primary objective of referential integrity is to prevent “orphans” in the database. i. Referential integrity is typically enforced with a primary key (PK) and foreign key combination (FK). A FK is a column or combination of columns in one table (child table) that takes its value from the PK in another table (parent table). ii. In order for referential integrity to be maintained, the FK in the “child” table can only accept values that exist in the PK of the “parent” table. iii. Referential integrity is most often implemented with a PK-FK combination, but triggers or stored procedures can also be used. iv. Please refer to Section 11, item 4 for information on foreign key indexes.
d. User-defined integrity - refers to specific business rules not covered by other integrity categories and is typically implemented through triggers and stored procedures.
SECTION 8: FDACS ENTERPRISE SYSTEMS AND DATA
To minimize duplication in collecting, processing, storing and distributing data and to enable the department to share data among the divisions and outside agencies, there are systems and tables which must be used in all application development. A division or office should not duplicate at the division level, the processes and data in the systems listed below.
SECTION 8.1: ENTERPRISE SYSTEMS
FDACS maintains an inventory of all applications/systems in the department in an Oracle web application named Department Information Systems Inventory (DISI) which is maintained in OATS by the data administrator. Read-only access is available to anyone in the department having an Oracle account in the DOA instance via the OATS intranet site. All Division Information Officers have update into DISI. When development starts on a new application, it must be added to DISI.
This application maintains a comprehensive inventory of business and technical components, application owners and descriptions and location of the data related to FDACS information systems and resources. It is used to produce reports for the Auditor General, Legislature and Governor's Office as well as used internally.
The other enterprise systems that are used by all divisions in an effort to minimize duplication of effort and ensure that the data being used by the divisions is as accurate as possible are:
1. Administration Imaging Management System (AIMS/TRAVEL) - this application includes online requests for travel, bids, requisitions, change orders, leases, vouchers and contracts with an electronic approval process and document imaging. The Travel module in AIMS provides an automated data entry application to capture and track the processing of travel documents and authorizations.
2. Agency Clerk Filings System - this application tracks the department's administrative actions involving fines and penalties of regulated statutes and rules that fall under agency
Page - 20 - of 113 Application Development Standards jurisdiction. The Agency Clerk Filing System provides a mechanism for program areas to input information regarding an administrative complaint and obtain a number that will be used to track the administrative action throughout the settlement process and filing with the agency clerk. This application allows fines to be tied back to revenue.
3. Contract Administration and Tracking System - this application tracks the department contracts in the Division of Administration Office of the Director. Contract Managers enter preliminary information into CATS by using the web based portion of Administration Imaging Management System (AIMS). The route slip is printed from the preliminary information and sent to the Office of the Director with the draft contract. The Office of the Director is responsible for assigning unique contract numbers and verifying the information for the contract before the contract is executed. E-mail is sent to all active contract managers each month as a reminder to review their contracts. 4. Coop and Personal Assets System - employee roles and emergency contact information has been added to the DACS employee tables to allow for this information to be stored/updated in one location. Supervisors and other authorized users are allowed to update the information from an intranet application for coop roles, business address and phones and emergency location. Home information will remain updated in State system People First. The Personal Assets portion of the system permits authorized individuals (usually department supervisors) to insert, query and update information about the various sensitive property items issued to department employees and external users.
5. Department of Agriculture and Consumer Services System - this application provides a means to maintain the department level tables such as the data related to personnel, firms, and look-up tables such as counties. It tracks employees as well as ops, contractors, temporary employees, and federal employees who perform work for the department. The employee roles (coop and others) are included as part of this system. The tables for address validation are also in the DACS schema.
6. Disbursements - this application allows department users to enter disbursement information, scan backup documentation, and forward the information to the Bureau of Finance and Accounting (F&A) for approval. When the disbursement is reviewed by F&A, it can be returned to the division for further information or approved. After approval, disbursement records are electronically uploaded to state FLAIR system. Users in the disbursement section can correct any errors and upload the records again. The application allows users to track the status of the disbursement through the process.
7. Enterprise E-Commerce System - this is an Internet Division of Administration web site for e-commerce. The division programs currently using e-commerce for payment from the public are the Division of Fruit and Vegetables CitraNet/Haulers subscription), Division of Agricultural Environmental Services (Pesticide Product Brand Registrations new and renewal), Division of Food Safety (Food Re-inspection Fees and Food Export Certificates) and Division of Consumer Services ((LPGAS license renewal, LPGAS training and class registration, LPGAS exam), Motor Vehicle Registration Renewal and Game Promotion/sweepstake and Do Not Call Purchase List). The application provides the public a way to renew and pay online (internet). This system allows for receiving and reconciling department revenues electronically; integration with department applications, department of financial services, flair, financial institutions. There is outsourcing of the gateway vendor Govolution and Bank of America.
8. Enterprise Imaging System – this is a web-based (intranet) document management system that is available to the department. A feature of the system is the capability of configuring multiple applications (categories of documents) and restricting access by
Page - 21 - of 113 Application Development Standards individual users and or groups of users. In addition, users and groups can be limited to a set of functions by individual or a role assignment. Administration, AgLaw, Plant Industry, Marketing, Agriculture Water Policy and AES are using the system.
9. Financial Information System - this application is a warehouse of the department's financial information. Many of the tables belonging to this schema are loaded from data received from the State FLAIR system each night. The disbursement subsystem is also part of the FIS schema.
10. Forms Management System - this application is used to manage the department forms which have gone through an approval process and have been issued an official form number. The primary user is the forms manager in the Division of Administration, but there is an intranet search feature that is used by all divisions.
11. GIS Enterprise Data Library - the GIS database library provides a direct link to current and accurate GIS base map layers needed for all department mapping products as well as linkage to program specific data that resides in division maintained Oracle databases and/or other SDE data libraries.
12. GIS Metadata Catalog - this application provides an inventory of all available spatial data in SDE available throughout the department and gives department GIS managers the ability to annotate their metadata
13. Remedy Asset Inventory - this application is the OATS Help Desk problem/call tracking database utilized by OATS personnel, DIOs, and all agency technicians. Reports produced include computer problem/resolution statistics, identifying training needs, identifying application/network or telephone system issues, and hardware maintenance contract compliance.
14. Revenue Online Collection - (ROC) internet portal allows any agency customer to pay renewal fees or invoices online. There is a single point of entry to ROC the via egov-online authentication system. Prior to ROC, the standard operating procedure was for the external customer to mail their payments and supporting documents to Finance and Accounting's revenue section to be processed manually. The ROC internet portal allows the customer to attach their supporting documents with their online payment. A cash sheet will continue to be sent to the divisions once payment has been received from payment processor and entered into the Revenue system. The Revenue Online Collection (ROCFDACS) intranet site provides the divisions a search screen to view the scanned documents that have been submitted by the customer.
SECTION 8.2: EMPLOYEE DATA
There is a centralized employee table in a schema called DACS in the DOA database that was deployed in 1999. A view of this table is available for all the divisions to use instead of duplicating or maintaining their own employee data. A specialized view can be created for each division so that the division views only their information. The initial employee record is created by the Bureau of Personnel when they receive a start date for a new employee. At that time, the minimum information necessary is input into the database: employee last name, first name, SSN, and organizational number. This allows for the user account information (Oracle, Network, etc) and the FDACS employee ID information to be linked to the employee record. To gain access to these tables, please contact the Division Information Officer for the Division of Administration, at 617-7023
Page - 22 - of 113 Application Development Standards There is an update process nightly from People First to populate the rest of the employee information when it has been input into the People First database. As of April 26th, 2006, employee business address information is being updated directly to the DACS Employee tables and not downloaded from People First. Employees update their home information in People First which is in the nightly download.
There is a Bureau of Personnel approved DACS.ALL_EMPLOYEES_V view of employee data for general use that contains OPS, Career Service, SES, SMS and external users (contractors, vendors, other State and Federal personnel). There are other views containing employee information by the employee type: DACS.EMPLOYEE_V DACS.OPS_EMPLOYEES_V DACS.EXTERNAL_USERS
Should your division require additional attributes for any of these views, you must contact the Bureau Chief for Personnel or the Assistant Division Director for Administration as some employee information is restricted and/or confidential.
The current attributes in the DACS.ALL_EMPLOYEES_V view approved by Bureau of Personnel for general use are:
Attribute Name Type PK NUMBER(10) CLASS_TITLE VARCHAR2(45) CRE_DATE DATE CRE_USER VARCHAR2(10) CONF_INDIC VARCHAR2(1) EMP_TYPE VARCHAR2(12) EMPLOYEE_ID VARCHAR2(10) END_DATE DATE FIRST_NAME VARCHAR2(25) FULL_NAME VARCHAR2(52) LAST_NAME VARCHAR2(25) MIDDLE_INITIAL VARCHAR2(1) MOD_DATE DATE MOD_USER VARCHAR2(10) NAME_CHANGE_INDIC VARCHAR2(1) NAME_PREFIX VARCHAR2(20) NAME_SUFFIX VARCHAR2(7) NICK_NAME VARCHAR2(10) ORG_CODE VARCHAR2(24) ORG_NAME VARCHAR2(45) POS_NUM VARCHAR2(6) SEPARATION_DATE DATE SWORN_INDIC VARCHAR2(1) TELECOMMUTE_INDIC VARCHAR2(1) VET_PREF_INDIC VARCHAR2(1)
The current attributes in the DACS.EMPLOYEES_V view (Career Service, SMS, SES only) approved by Bureau of Personnel for general use are:
Attribute Name Type PK NUMBER(10) CRE_DATE DATE CRE_USER VARCHAR2(10) LAST_NAME VARCHAR2(25) CDL_STATUS VARCHAR2(1) CDL_STATUS_DATE DATE CLASS_TITLE VARCHAR2(45) CONF_INDIC VARCHAR2(1) CONT_SERVICE_DATE DATE
Page - 23 - of 113 Application Development Standards CURRENT_MONTHS_SERVICE NUMBER(3) EDUCATION_LEVEL VARCHAR2(2) EDUCATION_MAJOR VARCHAR2(3) END_DATE DATE FIRST_NAME VARCHAR2(25) FULL_NAME VARCHAR2(52) HOLIDAY_TAKEN_DATE DATE HOME_COUNTY_NUM VARCHAR2(2) INITIAL_HIRE_DATE DATE LEAVE_ACCRUAL_DATE DATE MIDDLE_INITIAL VARCHAR2(1) MIDDLE_NAME VARCHAR2(25) MOD_DATE DATE MOD_USER VARCHAR2(10) NAME_CHANGE_INDIC VARCHAR2(1) NAME_PREFIX VARCHAR2(20) NAME_SUFFIX VARCHAR2(7) NICK_NAME VARCHAR2(10) NON_DRIVER_INDIC VARCHAR2(1) OLO_CODE VARCHAR2(4) OLO_NAME VARCHAR2(50) ORG_CODE VARCHAR2(24) ORG_NAME VARCHAR2(45) POS_NUM VARCHAR2(6) SEPARATION_DATE DATE STATE_DIRECTORY_NICK_NAME VARCHAR2(1) STATE_DIRECTORY_OMIT VARCHAR2(1) SWORN_INDIC VARCHAR2(1) TELECOMMUTE_INDIC VARCHAR2(1) VET_PREF_INDIC VARCHAR2(1)
The current attributes in the DACS.OPS_EMPLOYEES_V view (OPS only) approved by Bureau of Personnel for general use are:
Attribute Name Type PK NUMBER(10) CLASS_TITLE VARCHAR2(45) CONF_INDIC VARCHAR2(1) CRE_DATE DATE CRE_USER VARCHAR2(10) CONT_SERVICE_DATE DATE DUAL_EMPLOYMENT_INDIC VARCHAR2(1) EDUCATION_LEVEL VARCHAR2(2) EDUCATION_MAJOR VARCHAR2(3) END_DATE DATE FIRST_NAME VARCHAR2(25) FULL_NAME VARCHAR2(52) HOME_COUNTY_NUM VARCHAR2(2) INITIAL_HIRE_DATE DATE LAST_NAME VARCHAR2(25) MIDDLE_INITIAL VARCHAR2(1) MIDDLE_NAME VARCHAR2(25) MOD_DATE DATE MOD_USER VARCHAR2(10) NAME_CHANGE_INDIC VARCHAR2(1) NAME_PREFIX VARCHAR2(20) NAME_SUFFIX VARCHAR2(7) NICK_NAME VARCHAR2(10) NON_DRIVER_INDIC VARCHAR2(1) ORG_CODE VARCHAR2(24) ORG_NAME VARCHAR2(45) POS_NUM VARCHAR2(6) SEPARATION_DATE DATE STATE_DIRECTORY_NICK_NAME VARCHAR2(1) STATE_DIRECTORY_OMIT VARCHAR2(1) STUDENT_TYPE VARCHAR2(0)
Page - 24 - of 113 Application Development Standards SWORN_INDIC VARCHAR2(1) TELECOMMUTE_INDIC VARCHAR2(1) TOTAL_HOURS NUMBER VET_PREF_INDIC VARCHAR2(1)
SECTION 8.3: EXTERNAL USERS
There is a table in the DACS schema for housing the external users of our data and network (contractors, vendors, other state and Federal agencies). This table links the external user to a FDACS employee who is responsible for notifying the Help Desk when the external users’ account/access is no longer needed. It can also be used to store other information about the external users such as account names.
The current attributes in the DACS.EXTERNAL_USERS_V view are:
Attribute Name Type PK NUMBER(10) COMMENTS VARCHAR2(2000) CRE_DATE DATE CRE_USER VARCHAR2(10) EMP_PK NUMBER(10) END_DATE DATE EXTERNAL_EMAIL VARCHAR2(100) EXT_EMPLOYER_PK NUMBER(10) FIRST_NAME VARCHAR2(25) FULL_NAME VARCHAR2(52) INITIAL_HIRE_DATE DATE LAST_NAME VARCHAR2(25) LOCATION_BUILDING VARCHAR2(40) LOCATION_CITY VARCHAR2(80) LOCATION_STATE VARCHAR2(2) LOCATION_STREET VARCHAR2(80) LOCATION_ZIP VARCHAR2(5) LOCATION_ZIP4 VARCHAR2(4) MIDDLE_INITIAL VARCHAR2(1) MOD_DATE DATE MOD_USER VARCHAR2(10) NICK_NAME VARCHAR2(10) OPS_EMP_PK NUMBER(10) PHONE_NUMBER NUMBER(11) ROOM_NUM VARCHAR2(10) ANTICIPATED_SEPARATION_DATE DATE COOP_CONTACT_EMP_FK NUMBER(10) COOP_FUNCTION_FK NUMBER(10)
SECTION 8.4: EMPLOYEE OBJECTS
This table is used to store objects for an employee or external user such as Sonitrol cards, phone access cards, e-mail addresses, photo id badges, network user-id, Oracle user-id, purchasing cards, pagers, fuel cards, etc. Other objects could be added to accommodate the needs of the divisions.
The current attributes in the DACS.EMPLOYEE_OBJECTS_V view are:
Attribute Name Type PK NUMBER(10) CRE_DATE DATE CRE_USER VARCHAR2(10) ID VARCHAR2(30) OBJ_TYPE_PK NUMBER(10) COMMENTS VARCHAR2(255) EMP_PK NUMBER(10)
Page - 25 - of 113 Application Development Standards MOD_DATE DATE MOD_USER VARCHAR2(10) OPS_EMP_PK NUMBER(10) ISSUE_DATE DATE RETURN_DATE DATE DB_INSTANCE_NAME VARCHAR2(30) SONITROL_CARD_NUM VARCHAR2(15) PHOTO_NAME VARCHAR2(50) OUTSIDE_EMP_PK NUMBER(10) SONITROL_SECURITY_LEVEL VARCHAR2(2) DESCRIPTION VARCHAR2(250) LAST_MONITORED_DATE DATE REQUESTED_CANCELLATION_DATE DATE LU_EMP_OBJ_DISPOSITION_FK NUMBER(10) SERIAL_NUMBER VARCHAR2(100) ALT_ID VARCHAR2(100) MODEL_NUMBER VARCHAR2(100) RECEIVED_DATE DATE MANUFACT_FK NUMBER(10) PURCHASE_PRICE NUMBER(12,2)
SECTION 8.5: LOOK-UP TABLES
There are look-up tables in the DACS schema in the DOA instance for counties (DACS.LU_COUNTIES), countries (DACS.LU_COUNTRIES), divisions (DACS.FUNCTIONAL_DIVISION_BUREAU), FDACS organizations (DACS.LU_ORGS), phone numbers (DACS.LU_PHONE_TYPES) and others that should be used for consistency in the department. There are also look-up tables that must be used if collecting locational data (such as GPS, geo-coding, digital map interpolation). Those tables are:
DACS.LU_COLLECTION_METHOD DACS.LU_COLLECTION_MTH_TYPES DACS.LU_COORDINATE_ACCURACY DACS.LU_DATUM DACS.LU_OBJECTS_OF_INTEREST DACS.LU_POINT_PROXIMITY.
The department has address validation and geo-coding software available through procedures and web services. Information on the address validation would be available through the Information on the geo-coding services through the OATS Enterprise Platforms and Computer Operations Section (850 245-1065).
SECTION 8.6: ABBREVIATIONS AND ACRONYMS
Use abbreviations only when necessary. This makes remembering the spelling of the database entity easier. Try to remember that the users and other programmers will be trying to determine the contents of tables, packages, procedures, triggers, functions and columns by name. Abbreviations should be clear to the users, not codified for the developer. When using abbreviations, please review the approved list for the agency (Appendix 4) so that consistency is maintained (for instance using “num” instead of “no” or “#” for number). If the word is not on the list, refer to The Princeton Language Institute 21st Century Dictionary of Acronyms and Abbreviations (ISBN 0743486870) or check the following web site: http://www.acronymfinder.com/ .
Page - 26 - of 113 Application Development Standards
SECTION 9: ENTITY RELATIONSHIP DIAGRAM (E/R) GUIDELINES
SECTION 9.1: ENTITY
The representation of a distinguishable person, place, thing, concept, event or state which has characteristics, properties, or relationships, which are of interest to someone. The purpose of the e/r diagram is, at a minimum, to show relationships between tables. The same thing can be accomplished with a data model. A document showing relationships between data elements in databases is required Chapter 1B-26 FAC (see Section 6 of this document).
1. Entity name: a. Shall be unique within the application or schema (owner), but not within the agency. For example, more than one application within the FDACS might require an investigation entity. Prefixing the entity name with the application identifier (e.g. ST_INVESTIGATIONS, FOOD_INVESTIGATIONS, etc.) will uniquely identify the table within the database instance (e.g. DOA), thus allowing public synonyms and other benefits. Note: Refer to Appendix 3 for a list of already existing entities before naming a new entity. b. Shall be uppercase, singular and alphabetic with no special characters or dashes and cannot duplicate an Oracle reserved word. c. Entity name shall be brief but descriptive, Oracle allows 30 characters. Be sure to consider whether you will need public synonyms when considering the length of the table name. d. Each entity must have an appropriate description/definition.
SECTION 9.2: ATTRIBUTE GUIDELINES
Attribute is the name given to a representation of any detail that serves to qualify, identify, classify, quantify or express the state of an entity.
1. Attribute name must be: a. Upper case, singular and alphabetic with no special characters or dashes and cannot duplicate an Oracle reserved word. b. Brief but descriptive; maximum 25 characters. Date fields will have the word DATE included in the attribute name. For example, HIRE DATE. c. Attributes should be designated as the Primary Unique Identifier (UID), mandatory attribute (not null) or optional attribute (may be null) on the Entity Relationship Diagram
SECTION 9.3: PRIMARY UNIQUE IDENTIFIER ATTRIBUTES
Attributes that are part of a primary unique identifier (UID) will eventually be part of the primary key of a table. It should be listed first on the attribute list. Caution should be exercised when deciding what will be used as the primary UID for the entity/table. If there is any remote chance that the data might need to be changed in the future, do not use it as the primary UID.
An example of a change that occurred but was not expected is COUNTY_CODE, which originally was based upon county population is now done alphabetically. NAME shall not be used as a primary key of a table.
1. TABLENAME_PK or TableShortName_PK (example: emp_pk) is used for a UID that contains a system-generated number and is used internally during processing to access or
Page - 27 - of 113 Application Development Standards link data. The values are meaningful only as pointers or keys, and usually do not show on end user reports or screens.
2. When the primary key is based upon an intelligent data column such as PART_NUMBER, the primary key name will be in the format of the data column name, followed by an underscore followed by PK. PART_NUMBER would be PART_NUMBER_PK.
SECTION 9.4: RELATIONSHIPS
1. Each end of the relationship has a name that enables the user to understand the relationship easily. Remember that relationships are documenting business rules and will be used to explain the model to end-users. Refer to Appendix 5 of this document for examples of possible relationship name pairs. Relationships are bi-directional, that is, you should be able to read the relationship starting at either end:
Each department may be the employer of one or more employees. Each employee must be employed by one and only one department.
EMPLOYEE
employed by
employer of DEPARTMENT
2. The relationship name must be: a. Alphabetic b. Relationship text should be in lower case. Use single space as separator of relationship names. c. The degree of a relationship (cardinality) indicates how many entity instances may exist at one end of the relationship for each entity instance at the other end: d. A forked end (known as crow’s foot) signifies a relationship degree of “many”. Must be able to be read as being “one or more.” e. A single point signifies a relationship end degree of “one”. Must be able to be read as being “one and only one.” f. Minimize the use of bent lines and avoid crossing lines as much as possible.
3. The optionality indicates the minimum number of entity instances (rows) that are possible at one end of the relationship for each entity instance at the other end. a. A broken line signifies an optional relationship end. Must be able to be read as “may be.” b. A solid line signifies a mandatory relationship end. Must be able to be read as “must be.”
Page - 28 - of 113 Application Development Standards
SECTION 10: AUDITING
SECTION 10.1 AUDIT COLUMN
Audit capabilities are required in all systems developed for the agency. Auditing a table means keeping track of activities performed on the table. Every entity must contain the following four audit attributes:
1. CRE_DATE Date 2. CRE_USER Varchar2(30) 3. MOD_DATE Date 4. MOD_USER Varchar2 (30)
These audit attributes are to be detailed in the logical models for any entity. The columns will need to be populated by a database trigger fired upon insert and update of a row. Do not put these columns in the history tables.
SECTION 10.2 HISTORY TABLES
There may be situations where there is a need to know updates and deletes occurring on a table with a before look at the data. This would create the need for separate audit/history tables. These tables should have the name appended with HIST. Following the example will make the actual use of the history table easier. Record in MY_TABLE before update:
DATA MY_TAB_PK MOD_DATE MOD_USER CRE_DATE CRE_USER XXXX 10011 09-SEP-99 JONESP 02-MAR-98 SMITHT
Record in MY_TABLE after update:
DATA MY_TAB_PK MOD_DATE MOD_USER CRE_DATE CRE_USER SSSSSS 10011 25-DEC-99 BROWNW 02-MAR-98 SMITHT
Data in MY_TABLE_HIST after update:
DATA MYTAB_FK MOD_DATE MOD_USER CRE_DATE CRE_USER HIST_DATE HIST_USER XXXX 10011 09-SEP-99 JONESP 02-MAR-98 SMITHT 25-DEC-99 BROWNW ACTION_TYPE MY_TAB__HIST_PK U 000001
The MY_TABLE_HIST shows the record of MY_TABLE getting inserted when an update or delete of the record occurs. The data in the MY_TABLE_HIST will be the snapshot of the data before update or delete. NOTE: If the record were deleted, the MY_TABLE_HIST may be the only “snapshot” of what the data looked like before being deleted and who deleted the record. The MY_TABLE_HIST will also have its own PK (MY_TAB_HIST_PK).
The DBA section should be made aware of these history tables due to the possible growth potential. They will require monitoring and will be created in a separate tablespace called: ?_HIST_DATA and ?_HIST_INDEX.
Page - 29 - of 113 Application Development Standards
SECTION 11: MISCELLANEOUS ORACLE REQUIREMENTS
1. Do not use the data type "LONG." It has been deprecated as of Oracle 9i. Also, experience has shown that SQL*Forms do not work properly when an attribute with a LONG data type is included in a query. Consider using VARCHAR2 or LOB’s. If using LOBs, contact the OATS DBA section for assistance.
2. For alphanumeric columns, the VARCHAR2 data type should be used. The maximum length for VARCHAR2 is 4,000 characters. In assigning width to a column, allot enough space for all real future possibilities. Oracle does not store blanks at the end of VARCHAR2 columns as it does with CHAR. If a column is defined as VARCHAR2(30) but the actual data only needs 15 characters, it only stores the 15 characters. If a column has nothing in it (NULL), Oracle will not even store a blank space. The only effect that choosing a higher number will have is in the default SQLPLUS column formatting. SQLPLUS will create default headings the same width as the column definition.
3. Schema Creation- When requesting a new schema in a Development (DV) environment, an approved ITLC Project Charter should have already been submitted to the ITLC Review Panel. For new schemas in the Controlled Test (TE) and Production environments, please refer to the AP&P 1-2 for required deliverables. The following information needs to be provided to the DBAs for all application environments; this can be provided in a Change Log: a. Application full name b. Preferred schema name (usually application acronym) c. Estimated tablespace size requirements. The DBA section will create a minimum of two tablespaces for all applications, usually using the application short name, like FOOD_DATA and FOOD_INDEX. The tablespace should be specified in scripts for creating tables, indexes, primary keys, and unique key constraints. Please see the Section 14 on Tablespaces. d. Application specific roles required for the schema. Roles should be prefixed with the application acronym or identifier (LPGAS_USER) e. Script for creation of any public synonyms. Public synonyms must be prefixed with the application acronym or identifier. f. Information for the creation of any database links including the schema and database being linked to (Note: format for database link is Global_Database_name@connect_to_userid) g. Information for any Import or Export requested. 4. Un-indexed foreign keys are the biggest single cause of deadlocks in Oracle due to the fact that an update to a parent table's primary key or the removal of a parent record will place a table lock on the child table (no modifications to the child table will be allowed until the statement completes). This locks many more rows than it should and decreases concurrency and causes slow transaction time in the database. In addition to the table lock issue, an un-indexed foreign key is bad in the following cases as well: a. When you have an ON DELETE CASCADE and have not indexed the child table, the child table will be fully scanned once for each parent row deleted. b. When you query from the parent to the child. c. In general, the only time you do not need a foreign key index when all of the following conditions are met: o You do not delete from the parent table.
Page - 30 - of 113 Application Development Standards o You do not update the parent table's unique/primary key value, either purposely or by accident (via a tool). o You do not join from the parent table to the child table, or more generally the foreign key columns do not support an important access path to the child table and you do not use them in predicates to select data from this table. 5. Do not create objects under your personal username in production or test databases. In development databases, never create functions, triggers, packages, or procedures under your personal username that matches the name of one owned by an application user as you will not be able to execute it. These objects should be created by the application user (i.e. FOOD,LPGAS). After the application user creates a function, package or procedure, a public synonym must be created by the DBA section. Also, the application user must grant execute for the object to a role that will later be granted to the users needing to execute the object (GRANT EXECUTE ON object_name TO ROLE_NAME).
6. The DBA section needs to be informed of the progress of the application and require a minimum of two weeks’ notice prior to the application moving to production. This gives them the opportunity to do the server side requirements necessary on the production platform and time to review the scripts (DDL) for the objects that will be created for the application. A Change Log form located on the OATS Intranet site should be completed.
7. The DBAs will run the scripts (DDL) provided by the developers, which should include sizing for the tables and indexes. The object names should be prefixed with the schema name (e.g., create table schema_name.table_name). For more information see Section 16: Tablespaces #7.
The DDL scripts should be separated into the following:
01_cre_tbls.sql Create tables – include tablespace and storage clauses 02_cre_comments.sql Add comments 03_cre_views.sql Create views 04_cre_pk.sql Create primary keys (using “alter table…add constraint…”); include tablespace and storage clauses 05_cre_fk.sql Create foreign keys (using “alter table…add constraint) 06_cre_uk_ind.sql Create unique keys and other indexes, include tablespace and storage clauses 07_cre_seq.sql a) Do not use “nocache” (Caching sequences improves performance of inserts and bulk- loading). b) Don't use “order” (Using order negatively impacts performance). c) If it is necessary to guarantee the value is in order with no gaps, assign the value through the code.
Do not rely on sequences to be: a) gap free b) sequential c) always increasing d) only think of them as unique - nothing more, nothing less 08_cre_func_pkg.sql Create functions, packages, and
Page - 31 - of 113 Application Development Standards procedures 09_cre_trg_sql Create triggers 10_cre_syns.sql Create public synonyms 11_cre_roles.sql Create and grant database roles 12_gr_privs.sql Grant privileges needed for the system, for example: from schema owner to DAU or roles or from other schemas to schema owner, DAU, or roles 13_populate.sql Insert values into look-up tables, etc.
8. Use bind variables in “where” clauses whenever possible for performance enhancement. A bind variable is a placeholder in a query. For example, to retrieve the record for a particular employee, you can query:
Select * from employees where empno = :empno;
The value of empno would be supplied at query execution time. Bind variables allow a query to be compiled once and then stored in the library cache, from which it can be retrieved and reused multiple times. Everyone who submits the same exact query that references the same object will use the compiled plan.
9. No user or application will be granted Data Base Administrator privileges. No user will be granted Resource privileges except in development databases when specifically requested.
SECTION 12: GUIDELINES FOR NAMING DATABASE OBJECTS
SECTION 12.1: GUIDELINES FOR TABLE NAMES Review entity naming in the Entity section on page 9.
1. Use English words that are meaningful and descriptive with underscores used to separate words (e.g., field_tests). Oracle allows for 30 characters, but be careful to allow for the addition of _V to the table name for views and public synonyms.
2. Use plurals for table names.
3. Minor entity tables, also known as domain tables and look-up tables, should be prefixed with LU followed by an underscore (for example, LU_STATES, LU_COPES_CLASSES). These should usually (at the DBA’s discretion) be created in a special tablespace created for the application look-up tables (for instance: FOOD_LU_DATA, FOOD_LU_INDEX).
SECTION 12.2: GUIDELINES FOR COLUMN/FIELD NAMES
1. A column name should be the same as the name of the attribute from which the column was mapped, with the spaces translated to underscores. Oracle allows for 30 characters.
2. If the column is not based on an attribute, then it should be named using the naming standard set forth for attributes with the exception that an underscore is used instead of spaces.
3. A column name should not be plural.
Page - 32 - of 113 Application Development Standards 4. All columns that contain a date must have the word date appended to the name (such as BIRTH_DATE, HIRE_DATE).
5. The appropriate grants on the table or view will be made to ROLES. If users for select only need access, a role should still be created granting select on the view or table. Using grant select to public is discouraged due to data security issues.
SECTION 12.3: TABLE VIEWS AND TABLE SYNONYMS
1. If a view is created exactly like the table, the view name will be identical to the table name followed by an underscore and the letter “V”. An example would be EMPLOYEES_V. Oracle allows you to restrict access to the column level. Views created for report purposes or to restrict data, should have a name that describes its use, such as a view restricting employee data to a single division, might be named AI_EMPLOYEES_V for Animal Industry.
2. The appropriate grants on the table or view will be made to ROLES. If users for select only need access, a role should still be created granting select on the view. Using grant select to public is discouraged due to data security issues.
3. Applications will only use public synonyms, not private synonyms. The public synonym will be the object name preceded by an application identifier. For example:
Create synonym st_deposits for suntrack.deposits
4. Data Base Administrators will create the synonyms as required.
SECTION 12.4: PRIMARY AND FOREIGN KEY COLUMNS
If the primary key represents an unintelligent, system generated value (e.g. sequence); it should always be named Table_name_PK or tableshortname_pk. Only columns used in the table’s Primary Key constraint should end in “_PK”.
1. If the primary key is based upon an intelligent data column such as part number, the primary key name will be in the format of the column name, followed by an underscore, then PK. An example would be PART_NUMBER_PK. Only columns used in the table’s Primary Key constraint should end in “_PK”.
2. If the foreign key column references an unintelligent primary key column (Table_name_PK) it should always be named the referenced table name or table short name followed by _FK. A foreign key column referencing the EMPLOYEES table PK would be named EMP_FK. Only columns used in Foreign Key constraints (from the table they are referencing the PK of another table) should end in “_FK”.
3. If the foreign key column references an intelligent primary key column, it should always be named the referenced table name or table short name followed by the column name (abbreviated if necessary) followed by _FK. A foreign key column referencing the ORDERS table PART_NUMBER_PK would be named ORD_PART_NUM_FK. Only columns used in Foreign Key constraints (from the table they are in, referencing the PK of another table) should end in “_FK”. 4. History tables (named “
Page - 33 - of 113 Application Development Standards abbreviations may be necessary in order to keep the object name length less than or equal to 30 characters.
*Please see Section 11 – Item 4 for foreign key indexing.
SECTION 12.5: CONSTRAINTS
1. Constraint names must not exceed 25 characters in length. This limitation permits the constraint name to be used in the construction of the index name.
2. Constraint names will conform to the following guidelines. Any manually created constraints must conform to this standard.
a. Primary Key Constraints
Primary key constraint =