ICTDBS502 - Design a

database
These material is developed by Enhance Your Future Pty Ltd for Australian Institute of Science and
Technology (AIST)
 Determine database requirements
 Develop a logical data model
 Design the data structures
 Design queries, screens and reports
 Design access and security systems
 Confirm the database design
 TOPIC 1 – DETERMINE DATABASE
REQUIREMENTS

 Welcome to the unit ICTDBS502 - Design a database.

 This unit describes the skills and knowledge required to establish client needs and technical
requirements and to design a database that meets those requirements.
 It applies to individuals employed as database administrators and designers who are required to
design databases.
MEET WITH THE CLIENT, AND CONDUCT A
USER-NEEDS ANALYSIS, TO DETERMINE
DATABASE FUNCTIONALITY

 Database administrators and other personnel that are required to design and build databases often
meet with clients in order to determine what functionality will be required of the database.
 Conducting user-needs analyses is an effective method for accurately obtaining that information from
clients.
DATABASE

 A database is a collection of data that has been arranged into a structured system that allows for
pieces of data to be searched and selected or analysed according to predetermined identifying aspects
of each piece of data.
 Types of databases include:
 Commercial off-the-shelf (COTS) database packages
 Object-relational databases
 Proprietary databases
 Relational databases
USER-NEEDS ANALYSIS

 User needs analysis is the process of discovering what design elements and functionality must be
present, from a design perspective, based on the expressed needs of a client.
 Designers can employ a variety of tools and methodologies such as, interviews or the use of client
documentation to determine what clients’ needs are.  
 Once the client’s needs have been identified, designers can analyse the information by interpreting
each need as a function or design aspect of the proposed database.
 Clients that database designers encounter can vary vastly from one another.
ANALYSE THE RESULTS OF A USER-NEEDS
ANALYSIS TO IDENTIFY TECHNICAL
REQUIREMENTS

 The user-needs that have been collected by designers can be used to identify the technical
requirements of database design.
TECHNICAL REQUIREMENTS

 Technical requirements of a database are the elements that must be present in order for the database to
function according to the needs and requests of the clients.
 A client will reveal their goals and intended uses for the database.
 A user-needs analysis will also reveal what technical requirements exists based on the designer's
knowledge of database design and construction combined with information gathered during the user-
needs analysis.
 It is the job of the designer to make correlations between technical aspects of database design and
construction and the requirements found during the user-need analysis.
 Technical requirements can be related to many aspects of a database in its’ working environment,
including:
 Application of the database
 A business using the database
 The database itself
 The network that it will be run on
 Access to members of the organisation using the database
 The platform that the database will run on
 The operating systems that the database must run in
 The database will be accessed by internal staff from several departments as well as some of it
being shared with external vendors.
 A designer can determine from this information the following technical requirements:
 Amount of storage space needed to house the database
 What type of security to include for external parties and different organisational
departments
 How small to break the pieces of data should be broken down into, for example, the address
should be, country, city, postcode, street, building number
 Whether or not multiple languages will be required in the design of the database
 What relationships exist between data groups in relation to their users and uses
DEVELOP A CONCEPTUAL MODEL OF THE
DATABASE

 Developing a conceptual model of a database is the process of creating visual models of databases.
CONCEPTUAL MODEL OF THE DATABASE

 Conceptual models demonstrate:

 What data objects are included in a database
 How the objects relate to each other
 What rules govern the data objects
 Conceptual data models show what a database contains.
 The purpose of conceptual models is to define the scope, organize the data and define the business
concepts and rules.
 Conceptual models are most often created by designers, in conjunction with stakeholders by means of
user-needs analyses.
DESCRIBE THE DATA MODELLING RELATED
TO DEVELOPING THE CONCEPTUAL DATA
MODEL

 Developing a conceptual data model is the first type of model created during the full process of data
modelling.
 Essentially data modelling is a process of creating three data models, with conceptual being the first.
 Conceptual models are used to create logical data models, which are used to create physical data
models.
 Conceptual models are used to answer questions concerning what will go into the database.
 That information is used to determine how
the information will be implemented into a
full Data Business Management System
(DBMS).
 Example of a conceptual model:
SUBMIT THE CONCEPTUAL MODEL TO THE
CLIENT FOR REVIEW

 Upon completion of a conceptual model, it should be submitted to the client for review.
 The purpose of submitting conceptual models to a client for review is to ensure that the data in the
model and the relative manner in which the data is arranged is congruent with the requests and needs
of the client. 
 Reviews at the early stage of developing a database are extremely important.
 It is worth noting that prior to submitting a completed conceptual model, members of the design team
should go through review processes to ensure that the model is as close to client specifications as
possible.
SUBMIT THE MODEL FOR REVIEW

 Submission of conceptual models is an integral step in the process of designing a database according
to client needs.
 The manner in which all submissions and subsequent reviews are handled by a client may depend
greatly on how the process of submitting a conceptual model is handled, given that the conceptional
model is the first evidence of the actual structure of s database.  
 The model should be submitted in a manner that has been agreed upon in advance with the client.
THE CONCEPTUAL MODEL REVIEW
PROCESS

 Review sessions with clients should be carried out in a formal manner.

 The exact manner that a review is conducted will vary depending upon organisational practices and
terms discussed prior to commencing construction of the database. 
 Reviews processes information:
 Reviews may be conducted in a face to face format or remotely
 What is expected of each party involved in the review should be established prior to the
commencement of the review process
 Who is included in the review process will depend on the size, scope and stage of the review
process has been reached
EVALUATE CLIENT FEEDBACK AND MAKE
CHANGES AS REQUIRED

 The process of reviewing conceptual database models with clients involves evaluation of the models
than making appropriate changes according to the feedback.
 Typically a model is submitted to a client, the client gives feedback, and appropriate measures are
taken to address the feedback.
 It is the job of designers to consider and address every aspect of the clients’ request by adjusting the
model or demonstrating that the data in the model accurately reflects the data requested by the client.
CLIENT FEEDBACK

 Client feedback is any information regarding the conceptual model that is conveyed to designers.
 Client feedback may not be presented in a manner that immediately makes it recognisable as relevant
to a database or the current stage of the process of creating a database.
 Feedback can be in the form of a request for additional or altered data entities or for clarification
about how their requested data is represented in the conceptual model.
 It is the duty of designers to determine what changes need to be made based on client feedback.
EVALUATING FEEDBACK

 Designers should accurately evaluate how client feedback relates to conceptual models.
 Conceptual models represent what data will be included in a database, but do not fully demonstrate
how the data is handled.  
 Designers should ensure that feedback not related to the conceptual model is not used to alter the
model in a manner in which may ruin the integrity or functionality of the database.
 Effective communication with a client is equally as important as creating an accurate conceptual
model.
MAKE THE REQUIRED CHANGES TO THE
CONCEPTUAL MODEL

 Changes made to a conceptual model should improve clients’ ability to see the scope and understand
the basic concepts of the database.
 The three aspects that may be changed as a result of feedback are entities, relationships and attributes.
 Doing so may result in redrafting an entire model to ensure that all three aspects work together as
needed.
 Changes and adjustments made to the model after a review should be completed in a timely manner.
 TOPIC 2 – DEVELOP A LOGICAL DATA
MODEL

 IDENTIFY THE ATTRIBUTES AND DETERMINE THE DATA TYPES

 When developing a logical data model, it will be necessary to identify the attributes and to determine
the types of data that will be included in the database.
OUTLINE THE FUNCTIONS AND FEATURES
OF DATA TYPES AND DATA STRUCTURES

 In order to be able to design a functioning database, it will be necessary to be able to understand the
functions and features of the different data types and data structure.
DATA STRUCTURES

 Data structures are the manner in which the data is organised

within the database in order to enable queries and searches to be
conducted on them.
 Data will be structured in tables and will have definable
attributes and identifiers, such as keys that enable them to be
treated in a certain way.
 Data will be structured according to the type of database, and the
below diagram shows the structure for a relational database and
an object-relational database:
ATTRIBUTES

 An attribute within a database is a component within a database this may be:

 A table
 A column or row within a table
 A field
 It is important to identify all necessary attributes so that this information can be used to help design
the data structures of the database.
DATA TYPES

 There is a range of different data types that may need to be included in database design and it is
important that these are identified so that the database can be designed according to these needs.
 Common data types include:
 Numeric data types such as int, tinyint, bigint, float, real etc.
 Date and Time data types such as Date, Time, Datetime etc.
 Character and String data types such as char, varchar, text etc.
 Unicode character string data types, for example nchar, nvarchar, ntext etc.
 Binary data types such as binary, varbinary etc.
 Miscellaneous data types – clob, blob, xml, cursor, table etc.
 Diagram of the different data types:
UNDERTAKE THE NORMALISATION OF
ATTRIBUTES

 It will be necessary to undertake the normalisation of attributes in order to enable the functionality
and integrity of the database design.
ATTRIBUTE NORMALISATION

 Attribute normalisation is the process of organising the attributes in order to ensure that entity types
are consistent and that all relationships based on these will be consistent.
 The purpose of attribute normalisation is to prevent or minimise data redundancy by making sure that
all data is structured in a manner that allows it to be used by the database.
 Rules can be self-determined, or the following common rules may be applied:
DEVELOP AN ENTITY-RELATIONSHIP (ER)
DIAGRAM IN ORDER TO CLARIFY THE
CARDINALITY OF RELATIONSHIPS

 It will be necessary to develop an entry-relationship or ER diagram in order to clarify the cardinality

of the relationships.
 DEVELOP AN ENTITY-RELATIONSHIP ER
DIAGRAM

 An entity-relationship model is a diagram

that is designed to draw the relationships
that exist within a database.
 ER diagrams will explain the following
items about data:
 Example ER diagram:
CARDINALITY OF RELATIONSHIPS

 The cardinality of relationships is rated and explained by the number of unique or repeat entries that
are included in the data; high cardinality data is that which contains many unique entries.
 The cardinality of relationships can be identified by the following relationship types:
 Many-to-many
 Many-to-one
 One-to-many
 One-to-one
MANY-TO-MANY

 Many to many relationships occur when each of the records within two tables can relate to any, all or
none of the records in the other table.
 The representation of many to many data relationships will require the creation and use of a third
table.
MANY-TO-ONE

 Many to one relationship occur when multiple entries in the one table can relate to an entry in another
table.
ONE-TO-MANY

 One to many relationships occurs when a parent type data entry may have a range of attributes that
relate to it in one direction.
ONE-TO-ONE

 One to one data relationship occurs when the dataset only has one record on either side of the
relationship table.
 The table below is a graphical representation of the relationship types that may apply:
DOCUMENT ATTRIBUTES, NORMALISED
DATA, AND THE ER DIAGRAM

 It will be necessary to make sure that all database attributes, normalised data and the ER diagram are
documented according to organisational standards.
DOCUMENT ATTRIBUTES

 It will be necessary to document all attributes that apply to the database in order to make sure that
these are able to be used to make necessary decisions.
DOCUMENT NORMALISED DATA

 All of the data that has been normalised as a part of the process will need to be documented as a part
of the database design documentation.
 Normalised data may be documented using unified business modelling language in order to
communicate the normalised data.
DOCUMENT ER DIAGRAMS

 It will be necessary to make sure that consistent and compliant ER diagrams are documented suing the
agreed ER rules and format and making sure that the cardinality of all of the included information is defined.
 The following best practice tips should be used when documenting an ER diagram:
 Eliminate any redundant entities or relationships
 You need to make sure that all your entities and relationships are properly labeled
 There may be various valid approaches to an ER diagram. You need to make sure that the ER diagram
supports all the data you need to store
 You should assure that each entity only appears a single time in the ER diagram
 Name every relationship, entity, and attribute are represented on your diagram
 Never connect relationships to each other
 You should use colors to highlight important portions of the ER diagram
FORWARD DOCUMENTATION TO THE
CLIENT FOR CONFIRMATION

 Once the design documentation is complete, it will be necessary to forward the documentation to the
client for confirmation that the design is as desired and expected.
PREPARE DOCUMENTATION FOR
FORWARDING

 It will be necessary to check and assess all of the documentation to make sure that it is correct and contains all
of the required information.
 Documentation standards may include:
 Audit trails
 Data dictionaries
 Entity-relationship diagrams
 International Organization for Standardization (ISO), International Electrotechnical Commission (IEC) and
Australian Standards (AS) standards
 Naming standards
 Project management templates and report writing principles
 Version control
SUBMIT DOCUMENTATION TO THE CLIENT
FOR CONFIRMATION

 It will be necessary to make sure that the documentation is submitted or forwarded to the client using
the agreed method in order to make sure that the documentation is able to be reviewed so that the
client can confirm the database design and approve the next stage of development.
 TOPIC 3 – DESIGN THE DATA
STRUCTURES

 CONFIRM PRIMARY AND FOREIGN KEYS FOR TABLES

 As a part of the completion of the design structure, it will be necessary to confirm the primary and
foreign keys for all data tables.
UNDERSTANDING KEYS

 A key is any table attribute that is able to be used to uniquely identify the specific records that have
been placed within the table.
PRIMARY KEYS

 The first key type that is used to identify a data record

within a database is the primary key.
 The primary key must be one of the attributes of the record
that can be used as a suitable unique key for each of the
records.
 In the following example, the most suitable key identified
to assign as the primary key is the employee number:
FOREIGN KEYS

 The foreign key is a key that links the primary key from another entity to an attribute within the
current entity.
 The entity is known as foreign due to the fact that it is from another entity and not originating in the
current entity itself.  
 In the example below the primary key from the department table is the foreign key to an attribute in
the employee table (Names of attributes do not need to match as they will be scripted together):
 The diagram below demonstrates the differences between the primary and foreign keys:
CONFIRM THE KEYS REQUIRED FOR THE
TABLES

 It will be necessary to consider the different ways that the data is structured and that the data will
need to be used in order to confirm the primary and foreign keys that will need to be used.
REVIEW CLIENT BUSINESS RULES

 It will be necessary to review the client business rules that apply to the database design in order to
make sure that the design is compliant with these requirements.
BUSINESS RULES

 A client business rule in relation to a database is a statement that applies a constraint to a specifics
aspect of the database that is to be designed.
 Business rules can be created for any aspects of the database and may be applied to items such as:
 Elements allowable within a specific field
 Field specification requirements
 Relationship characteristics
 These rules are designed to make sure that the manner in which the data types are identified and
structured within the database will result in the required functionality of the database that is needed in
order to make sure that the database meets the client needs.
REVIEW BUSINESS RULES

 It will be necessary to review all of the business rules that have been provided by the client in order to
make sure that appropriate database design decisions are able to be made.
IDENTIFY THE REFERENTIAL INTEGRITY
CONSTRAINTS

 It will be necessary to identify the referential integrity constraints that apply to the database design.
REFERENTIAL INTEGRITY

 Referential integrity within all types of relational databases is the requirement that the relationships
that are stated must always be consistent.
 This means, for example, that a foreign key must always agree with the primary key that references
the foreign key.
 Therefore, is changes are made to the primary key these must be reflected in the foreign keys.
REFERENTIAL INTEGRITY CONSTRAINTS

 Referential integrity constraints are limitations that are applied to the manner in which entity or key
relationships are defined in order to make sure that they are always in agreement with each other and
consistent.
 It will be necessary to assess all of the relationship requirements and interactions in order to make
sure that all necessary referential constraints are able to be identified.
ESTABLISH DATABASE MANAGEMENT
SYSTEM CONSTRAINTS AND INCORPORATE
INTO DATABASE DESIGN

 It will be necessary to establish the database management system constraints and to make sure that
these are incorporated into the database design.
DESCRIBE DATABASE MANAGEMENT SYSTEM
(DBMS) FUNDAMENTALS, PARTICULARLY DURING
THE DESIGN PHASE

 A database management system is a software application that is used for the creation and
management of databases.
 A DBMS will be made of the following three fundamental elements:
 The physical database: the collection of files that contain the data
 The database engine: the software that makes it possible to access and modify the contents of the
database
 The database scheme: the specification of the logical structure of the data stored in the database
 The fundamentals of the database management system in relation to design include:
 The physical database will need to be designed in alignment with the particular database
management system to make sure that the data is able to be read and understood by the database
management system.
 The database engine will need to be considered in the design phase of the database to make sure that
data is able to be accessed correctly using queries and modified according to the needs of the user.
 The database scheme is the structure of the database and the data contained within the structures,
and it is important that these are completed according to the needs of the particular database
management system that is to be used to make sure that the two items are compatible with each
other.
DATABASE MANAGEMENT SYSTEM
CONSTRAINTS

 Database management system constraints are any limitations that may be applied to database
management due to the database management system:
 Features
 Functions
 Applications
 Allowable actions
DEVELOP THE VALIDATION RULES FOR
DATA

 It will be necessary to develop a range of validation rules that can be applied to the data held within
the database.
VALIDATION RULES FOR DATA

 Validation rules are rules that are used to verify and confirm that the data that is entered into the
database by users meets the necessary standards that apply before it is able to be saved.
 This prevents unusable poorly formatted data from being entered into the database.
 A validation rule can be developed to evaluate the data in a field or series of fields and provide a
response of either true or false.
 Validation rules can also be used to display error messages to users when invalid data has been
attempted to be entered into the system so that they can amend the data and then re-attempt to save it.
DEVELOPING SUITABLE VALIDATION RULES
FOR DATA

 It will be possible to develop data validation rules for a range of items such as:
 Objects
 Fields
 Case milestones
 It is recommended that validation rules be created and applied for all instanced where forms are used
to enter data into the database in order to make sure that all of the information that is saved to the
database by users will meet the business rules and will be able to be stored and used within the
database in an appropriate manner.
DESIGN INDEXES AND DEVELOP THE DATA
DICTIONARY

 The next step of the database design is to design the necessary indexes and to develop the data
dictionary.
DESIGN DATABASE INDEXES

 A database index is a type of data structure that is able to be used to improve the speed of the data
retrieval processes that are required as a part of database use.
 Indexes enable the search functions to be applied to the index tables instead of the search function
needing to scan all of the data entries in order to find the desired data component.
 Indexes will create parameters that can be applied to searches in order to make sure that the data
search will be minimised to only the section of data that has been identified in order to save time.
DEVELOP THE DATA DICTIONARY

 The data dictionary is a document that is used to define the elements of the data so that all of the data
that is stored within the database is able to be identified and categorised.
 The data dictionary should contain the following information for each data component:
 Metadata
 Table
 Description
 Name
 Relationships
DOCUMENT THE DATABASE DESIGN

 It will be necessary to document the database design in order to make sure that all organisational
requirements are met.
DOCUMENTING THE DATABASE DESIGN

 When documenting the database design, it will be necessary to consider the different types of
information that are to be documented and the most appropriate methods that can be used to achieve
this.
 The documentation of the database will commonly include:
 Design parameters documentation
 Relationship and data modelling
 Data structure diagrams
 Definitions and rules
 Reports on functionality
 Specifications sheets
 User documentation
ENSURE DOCUMENTATION MEETS
ORGANISATIONAL STANDARDS

 It will be necessary to make sure that the documentation meets organisational standards, and this may
include a range of items such as:
 Format
 Layout
 Level of detail
 Version control
 Style guides
 Design standards
 TOPIC 4 – DESIGN QUERIES, SCREENS
AND REPORTS

 DESIGN THE USER INTERFACE FOR DATABASE, INCLUDING MENUS, INPUT

SCREENS AND OUTPUTS
 It will be necessary to design the user interface for the database, and this should include the designing
of menus, input screens and outputs.
THE USER INTERFACE FOR THE DATABASE

 The user interface for the database is the graphic display or application that can be used for users to
input information and commands that are required to operate the database functionality.
 User interface elements that will need to be considered include:
 Interface elements include but are not limited to:
 Input Controls
 Navigational Components
 Informational Components
 Containers
MENUS

 Menus for the user interface for the database should be logical and make it easy for the user to
navigate to the different areas of functionality and control.
INPUT SCREENS

 The input screens will need to be configured in order to make sure that the user is able to input
queries, requests and commands in order to achieve their desired outputs.
OUTPUTS

 The outputs for the user interface should be considered and designed to meet the specific user needs
of the organisation.
 Output planning should consider:
 Types of outputs
 Format
 Visual display requirements
 There is a range of best practice elements that should be considered as a part of user interface design,
and these should include:
 Keep the interface simple
 Create consistency and use common UI elements
 Be purposeful in page layout
 Strategically use color and texture
 Use typography to create hierarchy and clarity
 Make sure that the system communicates what’s happening
 Think about the defaults
DESIGN QUERIES, BASED ON
REQUIREMENTS

 It will be necessary to make sure that a range of queries that can be used to collect information from
the database is able to be prepared.
 It is essential that these queries are designed based on the requirements of the client, user and the
organisation.
DATABASE QUERIES

 Database queries are the formal programmable requests that are made by the user input using the user
interface in order to retrieve specific information from the database as required.  
 It will be necessary to make sure that queries are written according to the programming language and
the type of database that is being used.
 The queries will need to be based on the data structures, types and other identifying factors that have
been applied to the database during the design and building phase.
REQUIREMENTS FOR QUERIES

 Requirements may relate to:

 Application
 Business
 Database
 Network
 People in the organisation
 Platform
 System
 Programming language
 Type of database
USE SQL SELECT TO RETRIEVE DATA FROM
THE DATABASE

 The select statement in SQL allows the queries needed to

retrieve the correct data from the database so that it can be
displayed on in the user interface as required.
 The select query can be tailored using a range of parameters
that will query the specific data that is required to be displayed.
 Specific SELECT statements can be structured using the
following order of conditions:
DESIGN OUTPUT REPORTS, BASED ON
REQUIREMENTS

 It will be necessary to design the output reports that will be able to be retrieved from the database.
 The output report design must be based on the requirements that apply to the specific database and
the context of its application within the organisation.
DATABASE OUTPUT REPORTS

 Database output reports are specific requests that can be made to report specific sets and volumes of
data that are set by the creating of report objects and commands that utilise the database structure and
content to meet the needs of the organisation.
 An object-orientated example of report objects is shown below:
DESIGN REPORTS BASED ON
REQUIREMENTS

 It is important to make sure that the reports are designed based on the user requirements that apply to
the organisation in order to make sure that users can request reports that will show the information
that they require in order to complete necessary work functions.
 When designing reports based on requirements, it will be necessary to plan:
 What reports types will be needed
 How the reports will be structured and requested
 Report output format and location
COMPARE THE PHYSICAL DESIGN WITH THE
CONCEPTUAL MODEL, OR USER-NEEDS
ANALYSIS

 The next phase of the design process will be to compare the physical design with the conceptual
model, or the user needs analysis.
THE PHYSICAL DESIGN OF THE DATABASE

 The physical design of the database refers to the tangible components of the database, such as:
 Data types
 Data structures
 User interface
 Queries
 Reports
 Functions
CONCEPTUAL MODEL

 The conceptual model is the diagram or plan that was developed in response to the user needs
analysis that was completed for the client, this will have been reviewed and agreed upon with the
client, and so it's important that the physical design achieved is compliant with these requirements.
USER NEEDS ANALYSIS

 The user needs analysis is a detailed investigation that was completed with the client in order to plan
the database according to the needs of the users.
 It is important to make sure that the physical design that has been achieved is compliant with the
identified user needs.
MAKE NECESSARY COMPARISONS

 It will be necessary to assess the physical design elements that have been created in response to the
development of the conceptual model or the user needs analysis in order to identify similarities or
differences with the requirements that apply.
INCORPORATE CHANGES AS REQUIRED

 Once comparisons of the current physical design of the database are made to the conceptual models
that were developed and the user needs analysis requirements that have been obtained it will be
necessary to incorporate any changes as required.
CHANGES THAT NEED TO BE MADE TO THE
PHYSICAL DESIGN OF THE DATABASE

 If there are any inconsistencies between the conceptual models or the user needs analysis information
that was created it will be necessary to make sure that these are identified and that changes to the
physical model are planned and undertaken as a result.
IDENTIFY NECESSARY CHANGES

 The specific changes that will need to be made can be identified from the comparisons that were
made of the physical database design to the conceptual designs, and user needs analysis that was
completed.
PLAN CHANGES

 It will be necessary to plan to make the changes to the physical model to make sure that it will be
compliant with the identified needs of the client.
 Plans will need to be made for:
 What will be changed
 How it will be changed
COMPLETE CHANGES IN A CONTROLLED
MANNER

 It is important that changes are made to the physical database in a controlled manner that applies
appropriate version control and changes management techniques in order to make sure that work is
able to be rolled back if required.
 All changes should be tracked and recorded.
 TOPIC 5 – DESIGN ACCESS AND
SECURITY SYSTEMS

 REVIEW THE BUSINESS SECURITY PLAN AS A BASIS FOR COMMENCING THE

ACCESS AND SECURITY DESIGN
 It will be necessary to review the business security plan as a basis for the commencing of the access
and security design that needs to be undertaken in relation to the database.
REVIEW THE BUSINESS SECURITY PLAN

 All organisations will have a security plan that outlines the standards and methods that apply to the
security of all ICT assets that are held within the organisation.
 It is essential that the business security plan is accessed and reviewed to make sure that all of its
requirements are able to be identified and incorporated into the planning process.
 Security plan may include the following information:
 Authentication
 Authorisation and integrity
 Privacy
 Security objectives of the organisation
USE THE SECURITY PLAN AS A BASIS FOR
COMMENCING THE ACCESS AND SECURITY
DESIGN FOR THE DATABASE

 It is important to make sure that the security plan is used as the basis for the access and security
design that applies to the database that is being created.
 It is important to make sure that access design meets that parameters regarding who can access
different data types and complete different actions within the database and how this will be ensured
using different security and ICT technologies and practices.
 It is important to make sure that security design protects the data when it is stored in the database,
when it is accessed and when it is transported and output.
DESIGN THE PASSWORD AND ACCESS
SYSTEM FOR THE DATABASE

 It will be necessary to design the password and access system for the database according to the
identified requirements of the business security plan.
EXPLAIN ENCRYPTION AND
AUTHENTICATION AS THESE APPLY TO
DATABASE SECURITY FEATURES

 Database encryption involves the process of applying algorithms to the data that is sent and received
from the database to enable it to be transformed into a type of cypher or encoded text which prevents
hackers from understanding or being able to read the text if it is intercepted.
 There is a range of different types of encryption that are commonly using in database design, and
these will vary depending on the type of data stored and the security plan requirements that apply to
the organisation.
DESIGN PASSWORD AND ACCESS SYSTEM

 Password and access systems are a type of access and authorisation system that is used to make sure
that only authorised and authenticated users are able to access the system.
 In order to design a password and access system for the database, it will be necessary to identify:
 User profiles and permission
 Authentication procedures and requirements
IDENTIFY MULTIPLE-USER REQUIREMENTS

 It will be necessary to identify multiple-user requirements so that this information can be used to plan
the access and password system design that is needed to protect the database from unauthorised
access and actions.
MULTIPLE USER REQUIREMENTS

 Multiple user requirements are the different requirements that apply to different user groups within
the organisation.
 As a part of the protection of the security and integrity of the data that is held within the organisation,
it is important to make sure that users are only able to complete the actions that they are required to
complete based on job function.
 User requirements for multiple users may include different permissions, such as:
 Types of data they can see
 Queries they can make
 Reports they can access
 Adding information to the database
 Removing information from the database
 Editing information that is held within the database
DEVELOP CLIENT ACCESS PROFILES USING
THE CLIENT BUSINESS MODEL

 It will be necessary to develop client access profiles using the client business model.
CLIENT BUSINESS MODEL

 The client business model refers to the manner in which the client organisation is structured in
relation to aspects such as:
 Departments
 Lines of authority
 Security clearance
 Permissions
 Authorisations to complete different actions
DEVELOP CLIENT ACCESS PROFILES BASED
ON THE CLIENT BUSINESS MODEL

 Client access profiles are the user accounts that will be developed for each of the different types of
personnel within the organisation.
 These accounts will have a range of permissions and authorities applied to them in order to make sure
that the security of the data is able to be maintained according to the needs of the organisational
security plans.
 TOPIC 6 – CONFIRM THE DATABASE
DESIGN

 IDENTIFY THE DATABASE BACKUP AND RECOVERY REQUIREMENTS

 It will be necessary to identify the database backup and recovery requirements that apply to the
organisation so that these requirements can be used to develop and document database backup and
restore procedures.
DATABASE BACK UP AND RECOVERY
REQUIREMENTS

 Different organisations will have a range of different backup and recovery requirements that apply to
the databases in order to make sure that organisational plans and standards are able to be met.
 These requirements may vary depending on:
 Data type
 Risk levels
 Compliance requirements
IDENTIFYING DATABASE BACKUP AND
RECOVERY REQUIREMENTS

 Database backup and recovery requirements may be identified through the access and assessment of a
range of information, including:
 Security plans
 Disaster recovery plans
 Organisational policies and procedures
 Compliance plans
DEVELOP AND DOCUMENT THE DATABASE
BACKUP AND RESTORE PROCEDURES

 Once the database back up and recovery requirements have been identified, it will be necessary to
develop and document suitable database backup and restore procedures.
DEVELOP BACKUP AND RECOVERY
PROCEDURES

 It will be necessary to develop backup and recovery procedures that are compliant with the identified
requirements that apply within the organisation.
 Development of database backup and recovery procedures will need to take the following factors into
consideration:
 Type of backup
 Frequency of backup
 Who will complete the backups?
 How will the backups be completed?
 Where will backups be located
 Recovery points that will be created
 Recovery data storage locations
DOCUMENT THE BACKUP AND RECOVERY
PROCEDURES

 Once all of the requirements for the backup and recovery procedures have been developed, it will be
necessary to document the procedures.
 Procedure documentation will need to be:
 Clear and specific
 Detailed and comprehensive
 Appropriately sequenced
SUBMIT THE DATABASE, AND
DOCUMENTATION, TO THE CLIENT FOR
FINAL APPROVAL

 It will be necessary to submit the database and all related database documentation to the client for
final approval.
SUBMIT THE DATABASE

 The database will need to be submitted as an:

 Application
 Fully functioning and installed item
SUBMIT DATABASE DOCUMENTATION

 It will be necessary to submit all of the database documentation to the client for final approval, and
this may include:
 Design documents
 User instructions
 Help manuals
 Specifications sheets
 Process maps
OBTAIN FINAL APPROVAL

 Once the database and the database documentation has been provided to the client, it will be
necessary to provide them time for review and then to obtain final sign off on the completed project
according to organisational procedures.
 TOPIC 7- REQUIRED KNOWLEDGE

 DESIGN A DATABASE
 Explain the process of data analysis, particularly in determining data types and data structures,
query and report design
 It will be necessary to explain the process of data analysis, particularly in determining data types and
data structures, query and report design.
THE PROCESS OF DATA ANALYSIS

 The process of data analysis involves the investigation and organisation of data to make sure that it is
able to be used for the purpose of the creation of a logical and operational database.
 Within the data analysis process, it will be necessary to:
 Gather information on the types of data that will be contained in the database
 Consider the different ways that the data is used by the organisation
 Categorise types and collate data into different sections
 Using ER models, it will be necessary to further analyse the data in order to determine the
relationships between them
 Models to depict the usage patterns of the data will need to be developed
HOW THE DATA ANALYSIS PROCESS CAN BE
USED TO DETERMINE DATA TYPES, DATA
STRUCTURES, QUERY AND REPORT DESIGN

 A good database that will meet the needs of the organisation will be structured in a manner that
represents that way that the data will be used by the organisation.
 When data is analysed, it will be possible to identify all of the data that is to be used in the database
and how it will be used by the organisation.
 This information can be used to determine the most appropriate and logical data types and data
structures that will be needed in order to be able to meet the needs of the organisation.
 Modelling and conceptual design practices should be applied to the analysed data in order to
determine what data structures and types will best support the queries and reports that the
organisation requires.
EXPLAIN HOW DATA REDUNDANCY IS
IDENTIFIED

 Redundant data is data which is contained in more than one place within the database, and so,
therefore, the database is larger than it needs to be.
 Data redundancy can be identified by:
 Normalising data
 Creating indexes
 Searching
 Data modelling processes
DESCRIBE THE FUNCTIONS, AND FEATURES,
OF DATABASES

 A database is a structured and organised set of related data that is able to be searched and queries
using programmable languages.
 Database features and functions include:
 Data storage
 Data management
 Data presentation
 Data security
 The ability for data to be added, deleted and updated as required
 Management of the information needs of the organisation
 Search and index functions
 Data structures and attributes to enable data management
DESCRIBE LOGICAL DESIGN CONCEPTS,
PARTICULARLY THOSE RELATED TO DESIGNING DATA
STRUCTURES, QUERIES SCREENS AND REPORTS

 The logical design of a database involves the process of creating a range of relationships
between the different data structures based on the manner in which they are logically
related to each other by business process or other logical requirements.
 Logical design concepts include organising data into:
 Entities
 Relationships
 Attributes
OUTLINE THE OBJECT MODEL DESIGN CONCEPTS,
PARTICULARLY THOSE RELATED TO DESIGNING DATA
STRUCTURES, QUERIES, SCREENS AND REPORTS

 Object-oriented programming is a programming concept that is based on the management of “objects”

which contain data which is the form of fields known as attributes and code.
 Objects can be then programmed with a range of variables that will define how the objects relate to and
interact with each other.  
 Many object-oriented programming languages are class-based and therefore will be managed using a
range of class variables as described in the diagram below:
 Object model concepts for designing data structures, queries, screens and reports
 Explain the term ‘scalability’ as it applies to databases
OBJECT MODEL CONCEPTS FOR DESIGNING
DATA STRUCTURES, QUERIES, SCREENS
AND REPORTS
 When using object model concepts for designing data structures, queries, screens, and reports, the
data will be divided into the following object groups and behaviours:
EXPLAIN THE TERM ‘SCALABILITY’ AS IT
APPLIES TO DATABASES

 Scalability is the ability of something to change size in response to a need.

 Scalability is of major importance to the management of databases, and there is a range of ways that
this is managed.
 The saleability of databases can be managed through:
 Set size databases
 Automatically scalable databases
 Partitions
 Vertical or horizontal scaling
 The use of distributed computers or servers
SUMMARY

 Now that you have completed this unit, you should have the skills and knowledge to establish client
needs and technical requirements and to design a database that meets those requirements.