- 1. Database Application Development Methodology - Assumptions
- 2. The Software Process
- 3. Overview of Methodology Data First
- 4. Digression: When Not To Use a Relational Database
- 5. Digression: Hierarchical Database
- 6. Example Project Description
- 7. Information Flow Diagram
- Requirement 01
- Requirement 02
- Requirement 03
- Requirement 04
- Requirements 05a
- Requirement 05b
- Requirement 5c
- Requirement 5D
- 8. IFD (Information Flow Diagram) Chart
- ✅IFD Version 0.2 on LineDance App
- 9. Don’t Go There
- 10. Specification V2
- 11. What Goes In Out the Database?
1. Database Application Development Methodology - Assumptions
2. The Software Process
Typical process phases:
- Business process design phase
- Analysis > Unique for Database Methodology
- Specification > Unique for Database Methodology
- Design > Unique for Database Methodology
- Implementation > Unique for Database Methodology
- Testing
- Operation
- Maintenance
In this course we only look at those which are unique for database development
3. Overview of Methodology Data First
In database application development methodologies data is always first. In general development process is often first.
So, they will concentrate on laying out diagrams in just the right way to get the functionality just the right way and then they hang the data where they fit. In database development it is data first. And once data is designed just right we will hang the processes on where they fit.
So, the 4 phases are:
(1) Analysis
(2) Specification
(3) Design and
(4) Implementation
So, the idea is that in the analysis phase we start with all the information that is provided by the customer and then the end product, the output of the analysis phase is an IFD (Information Flow Diagram). That diagram together with the information provided by the customer constitutes the input to the specification process.
Remember: Data first. So, in this specification process the first thing we do ist to create an ER diagram or EER diagram representing the data. With that as a foundation, then go ahead and create a specification of the tasks or applications that need to run on the database represented by this ER diagram.
Maybe, I also need some knowledge about RM (Relational Model)?
https://www.youtube.com/watch?v=OwdFzygGZqk or see this book:
4. Digression: When Not To Use a Relational Database
5. Digression: Hierarchical Database
6. Example Project Description
Learning by Doing
- Example | GTOnline - a lite social networking site for networking socialites, simple networking application that provides features similar to those in Facebook and LinkedIn
- Project | Case Study Description - GTOnline System https://video.udacity-data.com/topher/2021/April/607dc577_cs6400-gtonline/cs6400-gtonline.pdf
7. Information Flow Diagram
The squares represent input/output screens as seen in the requirements spec.
The arrows represent information flow. Very important: Information flow, not control flow. This is not a flow chart, this is a chart that shows potential information flow through the arrows.
Inside the system, there is a number of tasks, there is also a number of documents that we use to interact with the system. If you look at document D1, then D1 is an input doc for task #1 T1. T1 may then interact with the database by writing and reading from/to the database.
D2 is both, an input and output doc. T1 will read information from D2, will interact with the database, writing into the database and reading from the database and returning nformation to D2.
Requirement 01
D1 (Login Form) >> T1 pure input doc
All users are uniquely identified by their Email Address. Providing a valid Email Address and Password combination will log the user into the system. Providing invalid login credentials should display an error message and return the user to the login screen.
Requirement 02
D2 (Registration Form) >> T1 input, information will be written into the database
Users who are new to GTOnline must register first. A Register button is provided directly on the login page. Clicking this button displays the new user registration form. All fields on this form are required and cannot be changed at a later time. (Users who forget their passwords are just plain out of luck!) After the user clicks Register, the system should verify that all fields are filled in, that the Email Address has not already been registered, and that the Password and Confirm Password fields are equal. If any of these validations fail, the user should be returned to this screen to make corrections. The user should be provided with meaningful error messages so he or she knows what to correct.
Requirement 03
D3 (Edit Profile)
All GTOnline users (except administrative users) have a profile containing basic information. After a new user registers with GTOnline, they should be taken immediately to the Edit Profile screen. The basic profile properties include the user’s Sex, Birthdate, Current City, Hometown, and any number of Interests. The profile also contains information about the user’s education. The set of available Schools and their Types is maintained behind the scenes by the database adminstrator, so the user will select his or her school from a fixed list, instead of typing it in explicitly. A user can have any number of schools associated with his or her profile and can also provide a Graduation Date for each school. If a user has not yet graduated, the graduation date can be left blank. The interface should allow the user to add multiple schools and also delete schools from his or her profile in case of an error. It is also possible that the same school will appear multiple times with different graduation dates.
It is also possible that the same ProposedDance will be repeated (but not with different graduation types, but with different Achievements and/or Badges).
The profile also contains professional information. A list of employers is maintained behind the scenes by the database administrator. The user will select his or her Employer from the list and then provide a Job Title.
The User will select a ProposedDance from a list …
The Job Title field can be any value provided by the user—i.e., there is no preset list of job titles. A profile can contain multiple Employers and the same Employer may even appear multiple times as long as the Job Title is different in each case. The interface also allows the user to delete associated employers in case of an error. The only required fields on the profile are Sex and Birthdate. All the other fields may be left blank (e.g., no Current City, Hometown, School, or Employer information).
Requirement 04
D4 (View Profile)
There are a number of links on the View Profile screen:
- Clicking View Status Updates shows the latest Status Updates from the user (see Figure 9)
- Clicking View Friends shows the list of friends for this user (see Figure 8).
- Clicking Log Out signs the user out of the system and shows the login screen.
- Clicking View Pending Requests shows the list of friend requests that have not yet been accepted or rejected (see Figure 7).
- Clicking Edit Profile shows the Edit Profile screen allowing the user to make changes to his or her own profile (see Figure 3).
In addition to these links, two more links appear if the profile is that of the currently logged in user (i.e., if the user is looking at someone else’s profile, he or she will not see these options).
Requirements 05a
D5 (Search Form)
Request New Friend Screen is an input document.
The Search Form is an output document, it returns the search results based on the search criteria.
Social networks are all about making connections. GTOnline allows users to search for friends and connect to them. There are several steps involved in making a connection with a new friend on GTOnline:
- A user searches for a friend based on several profile criteria including Name, Email Address, and Hometown (see Figure 5).
- Then, the user submits a friend request to another user with whom they wish to connect (see Figure 6).
- Finally, the other user receives the friend request and accepts it or rejects it (see Figure 7). A significant difference between GTOnline and Facebook is that friendship is not always reciprocal in GTOnline. (Perhaps this is a better representation of real life!) This means, for example, that just because Emily is friends with Sarah, this does not imply that Sarah is friends with Emily. In other words, in order to establish a two-way connection between Emily and Sarah on GTOnline, both users must send friend requests to each other and both requests must be accepted. If, however, only Emily sends a request to Sarah and Sarah accepts it, then Sarah will appear in Emily’s list of friends, but Emily will not appear in Sarah’s list of friends (because Sarah has not yet made a request to Emily). Technically speaking, this means that your data model must differentiate the user who requested the friendship from the one who accepted it.
Requirement 05b
D6 (New Friend Request)
Requirement 5c
D7 (Pending Friend Request)
Requirement 5D
D8 (Friends List)
Output list from the database
8. IFD (Information Flow Diagram) Chart
The output of the analysis of the database application analysis methodology is an IFD.
Here is the information flow diagram that results from our analysis of the requirements. And below is the one I painted myself on the example.
The IFD is just a first high level specification of the system. As we analyse further the tasks of the system you will learn more about what they need to do. In spite of that it is not necessary to go back and refine this IFD. There is only so much you can code by boxes. Just take this as the first top level spec of the system which will form the basis for the next phase of the methodology.
The IFD clearly models the system that was specified by the customer.
✅IFD Version 0.2 on LineDance App
9. Don’t Go There
You might be tempted to that. That does not model the future system you are building.
10. Specification V2
We have modeled an IFD (Information Flow Diagram) . The next phase in our database application methodology is that of specifying. We are going to concentrate on specifying the database. In order to do that, we are going to look at the input and output documents to the system and we are going to use those to help us design an EER (Extended Entity Relationship) diagram representing a specification of the database. Subsequent to that we are going to look at the tasks of the IFD and from each one of those we are going to provide a specification of what the task will do relative to the input and output documents and the database that we are now designed.
The output of the specification phase will be an
- EER (Extended Relationship Diagram)
- Data formats
- Constraints
- Tasks decomposition
11. What Goes In Out the Database?
Two fundamental questions:
1) What goes into the database?
2) What comes out of the database?
Observations:
1) Everything in the database must come from somewhere
2) Everything in the input forms must go somewhere
3) Everything in the database must be used for something
4) Everything on the output documents must come from somewhere