Module 2 out of 9; SQLite training slides, databases, SQL, ERD, software design, database

1. MODULE 2: STARTING A DATABASE
PROJECT
SQL and Scripting Training
(C) 2020-2021 Highervista, LLC 1

2. 2
TOPICS
Business Rules and Use Cases
Statement of Work (SoW)
Data Dictionary

3. A PREVIEW: GETTING STARTED WITH A DATABASE
PROJECT
SQL and Scripting
Training

4. 4
HOW TO GET STARTED WITH A DATABASE PROJECT
1. Explore the project
a) Size, scope, depth and breath
b) Executive sponsor and/or funding
2. Review data to be modeled (for Capstone, NIH database)
3. Develop SoW (define scope, depth, limits)
4. Develop ERD (entities, attributes, relationships)
5. Normalize the Model (remove anomalies from the model)

5. 5
HOW TO GET STARTED WITH A DATABASE PROJECT
6. Apply the Normalized Model
a. Create the Database (create database)
b. Create tables with fields using Data Definition Language (DDL)
c. Create Data Manipulation Language (DML) to query (question) the data
7. Implement Functionality
a. Use Python to extract data from a data source
b. Load extracted data into the database
c. Be able to report on the data loaded into the database

6. 6
EXPLORATION OF THE PROJECT
Essential starter questions:
a) Size, scope, depth, and breadth
b) Executive sponsor and/or funding
This information is usually obtained in company meetings, IT staff meetings, previous project
documentation, etc.
The data collection and associated information will be used in the SoW, which we will
discuss.

7. BUSINESS RULES AND USE CASES SQL and Scripting
Training

8. 8
STARTING A DATABASE PROJECT
When starting a Database Project, we need to
understand, through research and user
interviews:
­ Use Cases are how users will specifically use the
database (for example; a user will add; a user will
change; a user will delete data in the database)
­ Business Rules are what we can/can’t do, or
restrictions and limits on the database (or software).

9. 9
WHAT IS A USE CASE?
In software and systems engineering (which includes database
development), a use case is a list of actions or event steps typically
defining the interactions between a role and a system to achieve a goal.
Use case = how to users interact with the software (database)
Example (via diagram): next slide
­ Typically, a diagram is used and supported by a narrative
­ UML is the most common use-case diagramming tool

10. 10
EXAMPLE USE CASE DIAGRAM (UML)
UML (Unified Modeling Language)
is diagramming software can be
used to identify many use cases in
a database and/or software system.

11. 11
BUSINESS RULES
A business rule is, at the most basic level, a specific
directive that constrains or defines a business activity
(related to use case).
These rules can apply to nearly any aspect of a business, in
topics as diverse as supply chain protocols, data
management, and customer relations.
Business rules help to provide a more concrete set of
parameters for an operation or business process.
Business rules are expressed in the RDBMS (ERD).

12. 12
BUSINESS RULE EXAMPLE 1
Finalized business rules must be bidirectional.
­ Draft: one sentence
­ Finalized: two sentences
A professor advises many students (professor to
student). Each student is advised by one professor
(student to professor).
A professor must teach many classes. Each class
must be taught by one professor.

13. 13
BUSINESS RULE 1
Business rules are used to define
entities, attributes, relationships, and
constraints.
Business rules explain a policy,
procedure, or principle.

14. 14
BUSINESS RULE 2
Sources of business rules:
Direct interviews with
internal & external
stakeholders
Site visitations (collect
data) and observation of
the work process or
procedure
Review and study of
documents (policies,
procedures, forms,
operation manuals, etc..)
When creating business rules, keep them
simple, easy to understand, and broad…
so everyone has a similar understanding and
interpretation.

15. 15
DISCOVERING BUSINESS RULES
Example on the class website
­ After reviewing and reviewing notes from the
interview and various forms, develop a set of
draft business rules.
­ For draft business rules, the initial narrative
does not need to be stated in bidirectional
relational manner and the narrative can use
less precise wording.
­ Iterative: Business rules are continually
developed; keep going until optimized.
­ Then, at one point when the rules are finalized,
business rules must state the bidirectional
relationship.
Source: Microsoft Images, used under license

16. 16
BUSINESS RULE EXAMPLE 2
A sales representative writes many
invoices. Each invoice is written by one
sales representative.
Each sales representative is assigned to
many departments. Each department has
only one sales representative.
A customer generates many invoices. Each
invoice is generated by only one customer.

17. 17
SUMMARY: PROCESS FOR USE CASES AND
BUSINESS RULES
Start documenting use cases (list how users will use the software/database)
­ Example: Our users will:
­ extract data from the National Institutes of Health Database
­ report on the extracted data
Identify business rules (items that define, restrict, or even enhance the
software)
­ Example: We must comply with state-mandated security requirements for our customer
records.
This is not a one-pass item: It is iterative.

18. 18
WHAT IS A STATEMENT OF WORK (SOW)?
The SoW is the document that captures and defines all aspects of your
project. You’ll note the activities, deliverables, and the timetable for the
project. It’s an extremely detailed document that will lay the groundwork
for the project plan.
It’s one of the first documents you’ll create to lay out the landscape of
the project before you plan and execute. Because of the amount of
detail required, the prospect of writing one can be daunting. Therefore,
let’s break it down into more digestible parts.

19. 19
SOW: THE BIG PICTURE

20. 20
SOW – A FEW KEY STEPS
What is the purpose of the project? Start with the big question: Why are you initiating this project? Why does
the project need to be done? Create a purpose statement to lead off this section and provide a thorough
answer to these questions. Examples: What are the deliverables, objectives, and return on investment?
Scope of work: What work needs to be done in the project? What is the process you’ll use to complete the
work? This includes outcomes, time involved, and even general steps it’ll take to achieve that.
Where will the work be done? The team you employ will have to work somewhere. The project might be site
specific, at a central facility, or some, if not all, the team members could work remotely.
Tasks: Take those general steps outlined in the scope of work and break them down into more detailed tasks.
Be specific and don’t leave out any action that is required of the project to produce its deliverables.

21. 21
SOW STEPS
Milestones: Define the amount of time that is scheduled to complete the project, from the start date
to the proposed finish date. Detail the billable hours per week and month, and whatever else
relates to the scheduling of the project.
Deliverables: What are the deliverables of the project? List them and explain what is due and when
it is due.
Schedule: Include a detailed list of when the deliverables need to get done, beginning with which
vendor will be selected to achieve this goal, the kickoff, what the period of performance is, the
review stage, development, implementation, testing, close of the project, etc.

22. 22
KEY CONCEPT: DATA DICTIONARY
As you are examining your data and developing a preliminary concept of what your
ERD will be, save your work in a data dictionary.
A data dictionary is an organizing tool that consists of the following information:
­ name of the tables in the database
­ constraints of a table: i.e., keys, relationships, etc.
­ columns of the tables that related to each other
­ owner of the table
­ last accessed information of the object
­ last updated information of the object
­ and more …

23. 23
DATA DICTIONARY (USE A SPREADSHEET)
Source: McFarland, 2020

24. 24
TYPES OF DATA DICTIONARIES
Active Data Dictionary
­The DBMS software manages the active data dictionary automatically. The
modification is an automatic task, and most RDBMS have an active data
dictionary. It is also known as an integrated data dictionary.
Passive Data Dictionary
­ Managed by the users and is modified manually when the database structure changes. Also known as a non-
integrated data dictionary.
For the Capstone, we will use a Passive Data Dictionary.

25. 25
DATA DICTIONARY AND THE SYSTEM
CATALOG
Data Dictionary: contains metadata to provide detailed information of
all tables within the database
System Catalog: a very detailed system data dictionary that describes
all objects within the database
­ It is a system-created database whose tables store the database characteristics
and contents.
­ Its tables can be queried just like any other table.
­ It automatically produces database documentation.

26. 26
DATA DICTIONARY (DATATYPE & FIELD LENGTH ARE NOTED)
Source: McFarland, 2020

27. 27
DEFINING DATA TYPES
We have entities, attributes, and relationships (a first pass).
Collect the information in your data dictionary.
Add into your data dictionary the field name, data type, and field
length for each attribute. Be sure to include a detailed description of the
field name, too.
­ Example attributes:
­ Data_Sequence_no:
­ Spl_version:
­ Published_date:
­ Title:
­ Setid:

28. 28
SQLITE DATA TYPES
NULL. The value is a NULL value.
INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending
on the magnitude of the value.
REAL. The value is a floating-point value, stored as an 8-byte IEEE floating point
number.
TEXT. The value is a text string, stored using the database encoding (UTF-8, UTF-16BE
or UTF-16LE).
BLOB. The value is a blob of data, stored exactly as it was input.

29. 29
DEVELOP A PRELIMINARY DATA DICTIONARY
Develop a preliminary data dictionary for the Capstone project. At present, not all
items are known. Please keep in mind that this document is iteratively developed. The
data dictionary should include the following items:
• Develop a template using Excel that you will eventually use for the Capstone. For the first pass, fill in as much as
you can (column headings/rows). Keep in mind that the data dictionary will be constantly revisited during the
project life cycle. You are not expected to have this done on the first pass!
• entities/tables • field defaults
• attributes/fields (within entities) • relationships
• primary key/foreign key • descriptions (for entities, attributes, descriptions)
• field data type and size • where each field is used (report, screen, etc.)

30. 30
REFERENCES
McFarland, R. (2020). Published Articles: Ron McFarland.
Retrieved December 03, 2020,
from https://medium.com/@highervista
Shenoy, S. (2020). “Developing A Project Charter: One of the Critical
Documents of Project.” PM Exam Smart Notes. Retrieved
December 03, 2020, from
https://www.pmexamsmartnotes.com/develop-project-charter-
process/

31. 31
INTRODUCTION
Ron McFarland
Technologist, Educator
Source: Microsoft Images

32. 32
ABOUT THIS COURSE
This course is distributed free. I use several
sources. But importantly, I use the book noted
on the next slide.
If you are using these PowerPoints, please
attribute Highervista, LLC and me (Ron
McFarland). IN ADDITION, please attribute
the author noted on the next slide, as the
author’s textbook provides essential
information for this course.
Source: Microsoft Images

33. 33
INTRODUCTION
This course is offered to you free. HOWEVER, please
purchase the following book, as it is a primary resource for
this course. I do not make any $ from this course or this
book. So, since a handful of good content is derived from the
following text, please support this author!
Title: SQL Quickstart Guide
Author: Walter Shields
Available: Amazon, B&N, and through ClydeBank media
website at:
https://www.clydebankmedia.com/books/programming-
tech/sql-quickstart-guide