|BOMS Object/Application Registry:This registry is designed to meet the state policy to reduce duplication of effort and cost in developing application software. All Snap-in applications will be registered and available to circuits. Agreements will be negotiated as appropriate to implement a snap-in at reduced cost. The vendor will only charge installation, conversion and implementation charges for these applications.
Core Database: The core database is the database and applications that are accepted as the basic BOMS/STAC systems and is maintained under the basic service level agreement (SLA).
Custom Application: An application that is contracted between CIP and a circuit for an application that uses the information from the core BOMS database. Custom applications are the responsibility of the individual circuit and fall outside of steering committees.
Customer: The circuit that purchased the application and is responsible for the success of STAC/BOMS in meeting the business requirements of the office. The Customer agrees to support the recommendations of the STAC/BOMS Steering Committee and to work in conjunction with the committee for any changes and modifications to the STAC/BOMS system as well as operating systems that are required to run the application. The customer will provide the proper level of staff training to insure the successful implementation of STAC/BOMS. To insure that there is acceptance and commitment at all levels within the organization prior to the installation and implementation.
Customers/PB2: Individuals or groups external to the State Attorneys who directly receive S.A. services/products/outputs. If S.A.s charged money for their services/products, customers are the people/organizations that would pay the bill for services rendered.
Data Dictionary: A data dictionary contains detailed information about database tables. Many DBMS programs include an automated data dictionary as part of the program. In this way, all the information about a database is captured into a document as the database is created. Therefore, the database design (showing all the tables and their relationships, primary keys, foreign keys), and the properties of a database (fields, data types, validation rules, size of the fields) can be easily referenced by the developers and the users of a database system. Since there are no standards for data dictionaries, the way the information is arranged will vary from DBMS product to DBMS product. Each data dictionary, however, includes the following information:
A list of tables and a description about what they contain:
DEPARTMENT Data about each department
FACULTY Data about each Faculty member
COLLEGE Data about each College in the District
COURSES Data for each course in the college
Example: (FOR EACH TABLE)
FIELD Data-type Size Key Rules/Required/notes
(Length) (primary or foreign)
AcctNum Text 12 Primary Required
CustName Text 25 N Required
CustAddr Text 25 N Required
City Text 10 N Required
Field is the name of the item in the table, such as CustName
Data-type specifies whether the item is one of the following: Text, Number, Date, Logical (T/F), Currency, etc.
Size shows the number of characters (bytes) allowed for this item occupies in record. For example, a currency amount of 999.54 has a length of 5 bytes, 2 of which are decimal places (the decimal point itself is not stored)
Key indicates if this item is a unique identifier for PRIMARY this record; sometimes keys are actually compound items; Keys are UNIQUE, which means that no other record in the table will have the same value in this item; for example, SSN is unique in a student record; AcctNum is unique in a customer record.(PRIMARY KEY) "key" indicates that a field relates the record to FOREIGN another table in the database. Not all tables have a foreign key, but if they do, it is a required field; otherwise the link to the related table cannot be established (THIS concept is called "referential integrity" - a foreign key must contain a value already stored in the related table) (The account table above does NOT have a foreign key).
Rules indicates that only certain values are allowed for this field. An example: a field for marital status must be an M, S, D, or W only. (see ASSIGN17.106 for more on validation rules)
Required indicates that the field cannot be left blank when the record is added to the table. The field must
have SOME value, and cannot be NULL. The term "NOT NULL" means that the field cannot be left blank. ("Rules? and "Required? are referred to as "Validation rules").
Format helps the user or developer understand the format that is used for storing data in this field, such as: PHONE use area code-prefix-number (example: 214-324-7116)
The Validation rules and formats are used when creating a data-entry form for entering and changing data in a table. By referring to these rules the developer can create meaningful messages if the user enters invalid data. This helps keep incorrect data out of the database.
After the data dictionary is created:
The data dictionary is then used to make sure that all items that the user needs have been included in the tables. It is also used by the database developer to set up the database and, to develop the data entry forms, forms for viewing data, reports, and queries.
Many DBMS products will generate a printed data dictionary after all the tables have been set up. This makes good documentation, but does not assist in developing the database in the first place. The database developer must create for her/himself some sort of chart or word-processing table to help keep track of all the database information when she/he is designing the database. The Data Dictionary lab assignment will help you understand this process.
FDLE Data Element Dictionary: A list of data dictionary specifications published to create continuity of databases so that information can be shared between systems and allow for uniform reporting. FDLE coordinates the data dictionary as part of its legislative requirement and by direction of the Criminal Juvenile Justice Information Systems Council.
NCIC Data Element Dictionary: A published list of data elements that was developed to provide a common data reporting system. It is managed by the FBI and coordinated by FDLE.
Object: An element of an application or program. This is typically module such as a report or query function that can be copied and used again in another application. It requires a common data dictionary and data element structure to work effectively.
Object Reuse: The reuse of objects to reduce programming and report writing efforts. It is used typically in conjunction with performance based budget principles.
Office of Program Policy Analysis and Government Accountability (OPAGA):
Outcomes: The strategic or overall effect of doing something.
Outputs: The objectives that are to be accomplished. Typically a list of specific things to be accomplished to effect an outcome. Outputs should be measurable.
Performance Measures: Elements of an expectation the can be measured. A list of measurable actions or defined results.
Service Level Agreement (SLA): A service level agreement presents specific services that will be provided. It also outlines conditions and expectations that both the vendor and the customer are to do to successfully maintain a level of satisfaction.
Snap-in: An application or object that integrates with the core database but is designed for a special function. The snap-in may be developed for an individual circuit or a consortium of circuits. The cost of the snap-in will be born by the individual or consortium. Use of the snap-in by additional circuits will be with the individual or consortium?s permission and in keeping with current legislative policy as to software reuse. The snap-in will be reviewed by the steering committee and registered into the BOMS object/application resource registry. The snap-in will include a service level agreement (SLA) that will insure that the cost to maintain the snap-in to the current version level of the core BOMS application.
Special Projects: A special project falls outside of the normal database application. There are two types of special projects.
Stakeholders/PB2: Individuals or groups who are not customers and who have something to gain or lose if the S.A.s do well or not in their jobs. Stakeholders are affected by the S.A. either directly such as the Governor and Legislature or indirectly such as the Department of Corrections or local jails. Stakeholders include individuals and groups working within the S.A. Offices because they have a lot personally and professionally at stake.
STAC Object/Application Registry: This registry is designed to meet the state policy to reduce duplication of effort and cost in developing application software. All Snap-in applications will be registered and available to circuits. Agreements will be negotiated as appropriate to implement a snap-in at reduced cost. The vendor will only charge installation, conversion and implementation charges for these applications.
STAC Steering Committee: Members are representatives of the customer that make recommendations and set policy for the STAC core application capabilities. The committee agrees to provide leadership and business function expertise to maintain STAC at a level to meet the business requirements of the State Attorneys Offices within the State of Florida. To allow the flexibility for individual offices to meet individual requirements through application and object "snap-ins".
Vendor: CIP is responsible for delivering the application as specified by the customer and steering committee. The Vendor agrees to support the recommendations of the STAC Steering Committee and to work in conjunction with the committee for any changes and modifications to the STAC/BOMS system