Sex, BirthDate, CurrentCity, and HomeTown are all single-value property types. Interests is a multi-value property type modelled by the double ellipse.

Notice, that I am very careful to use the names that are provided in the Requirements Specification documents in my EER diagram. That way I tie the diagram very, very closely to document. The idea is that the EER really becomes a high-quality model of reality. Reality represented by the documents

The Users actually have 2 subtypes: RegularUsers and AdminUsers

Requirement: All GTONline Users (except Administrative Users) have a profile containing basic information about them.

What do we learn from that?

We learn that they are not just Users, they are also AdminUsers. The way we specifiy this, is as follows:

A list of Schools, from which the User can select, is maintained in the system (System Administrator). Assume that all SchoolNames will be unique (therefore Identifying). A User can have any number of schools associated with him or her and can proclaim GraduationDate for each School. It is possible that the same School will appear multiple times with different GraduationTypes.

For a particular School, there may be many RegularUsers that may have attended that School.

So, given one School, there may be many RegularUsers associated with that .

In a unique relationship instance between a RegularUser and a School, there is a YearGraduated associated with it. Since the may attend the same School for many different levels of education like Bachelors and Masters for example, the YearGraduated is a multi-value.

For a particular ProposedDance, there may be many Users that may have exercised that .

So, given one ProposedDance, there may be many Users associated with that .

In a unique relationship instance between a User and a School, there is a DateDanceWasExercised associated with it. Since the User will exercise the same ProposedDance many times, the is a multi-value.

Each School must have a SchoolType. There are four possible types: College/University, High School, Middle School, and Elementary School. It should be possible for the administrator to add new SchoolTypes from behind the scenes.

Each ProposedDance will have a ProposedRepetitionRate for a CertainDay. There are zero to three dances to be repeated per day. It should be possible for the administrator to add new DanceRepetitonRates from behind the scenes.

Just like a RegularUser can have multiple SchoolsAttended, a egularUser may have had several Employers.

Here you see the screen, an AdminUser uses to maintain a list of Employers.

Administrators are responsible for managing the list of Employers. Assume that all Employers have a unique EmployerName.

So, we have an entity type of Employer

A RegularUser may have multiple Employers, and obviously a particular Employer may have multiple RegularUsers.

The JobTitle is not managed by the AdminUser and can be any value provided by the RegularUser. A profile can contain multiple Employers and the same Employer may even appear multiple times as long as the JobTitle is different in each case. It is a multi-value, because over time a particular RegularUser may have held different JobTitles for this same Employer.

So, we have an entity type of Badges.

A User may earn many Badges, and obviously a particular Badge may be awarded to multiple Users.

A UserProfile can contain multiple Badges and the same Badge is connected to multiple Users, which the User earned with various, different Achievements. JobTitle is a multi-value, because over time a particular User will collect many different Achievements under the roof of the same Badge.

In the Pending Requests document (screen), the list of people who have requested to be friends with you. And below is the list of people that you have requested to be friends with.

A particular User can request multiple other Users to be friends. For each one of those requests, there is an instance of the Request Relationship. So, one RegularUser may have requested several different Friendships.

When a User accepts a Request that adds an instance to the Accept Relationship. So, a particular RegularUser may have accepted Friendship from multiple different Users. The DateConnected records the date that the invitation was accepted.

Friendship is not always reciprocal. Just because Emily is friends with Sarah, this does not imply that Sarah is friends with Emily.

The DateConnected field is set when the friend request is accepted, not when the request is originally sent.

(1) Lookup vs Insert, Delete, and Update?

Different database locks

From a DBMS perspective, there is a big difference between whether a task just is a Lookup task or whether it modifies the database through an insertion, deletion, or update.

The reason for that is that different database locks are needed in order to support lookup versus changes to the database.

If many different things take place, then that is an indication, that the task should be decomposed.

(3) Are Enabling Conditions Consistent Across Tasks?

Let run, what can run - scheduling

The next rule of thumb is based on what enables the different portions of a task. If some portions of a task are enabled, why not let those proceed instead of waiting to later on, when there might not be resource available to run those tasks that were earlier enabled?

The smaller portions of a task that can run, the easier it is to schedule the task.

(5) Is Consistency Essential?

ACID transaction properties

The next, really important rule of thumb is related to consistency of the database: Is it really essential that all the pieces of a task get done in one transaction, or is it ok that things get spread out a little bit over time.

An example of that would be transferring money from one bank account to another one. It is very important that all the steps involved are done together. For example - money must be available in the from-account, they must be subtracted from the balance of the from-account and they must be deposited in the to-account. All of those tings must be done together in order that you do not end up with an inconsistent database.

(2) How Many Schema Constructs are Involved?

Many database locks

The 2nd rule of thumb is based on how big a portion of the database is involved in the operation.

The bigger the portion is, the harder it is to acquire all the locks that I needed in order to support concurrent execution of transactions on the database.

So, if a large number of schema constructs are involved that would make you want to decompose the tasking to smaller tasks using smaller portions of the database

(4) Are Frequencies Consistent Across Tasks?

Index only what must be indexed

The next rule of thumb is based on what the frequencies of the things that are done by the task are.

If the task contains things that are done with a high frequency and things that are done with a low frequency, it is a good idea to split them apart. The reason is, that high frequency things you want to index to run fast, whereas low frequency things you may not need to index.

👀(6) Is Mother Task Control Needed Or Not?

Sometimes you need a mother task, sometimes you do not.

The banking example from before certainly needs a mother task.

We are later going to see things that may not need a mother task

Web Apps

Web based applications are almost completely stateless.

The amount of state maybe as little as the login information for a session user

There may be a small amount of clickstream data that is available in order to proceed with hte application.

Things however for web-based applications are changing. With new technologies such as Web2.0 and AJAX, it is now possible to provide much more state information with the application on browser level or behind the scenes on the server (but not in the database).

Because of that, web apps are beginning to act more like traditional applications.

Traditional Apps (sowas wie ACCESS DB?) (Oder eine alte, native App?)

In a traditional application, it is much easier to manage local state separately from the database (e.g. using smart widgets)

That means that a whole bunch of changes can be collected before submitted to the DBMS for execution.

That means, that there is not a run-trip to the DB needed. Every single time, a minor thing is changed, such as you have to do in a web app.

Traditional applications are much better to control support of ACID transaction properties. So, that is a big advantage.

Decompose the View Profile into

• View Personal
• View Education
• View Professional

That is the task that supports the View Profile Screen (document). By looking at the screen, we notice that,

• there are 3 lookups (Suche?)
• Personal information
• Education Information
• Professional Information

for a RegularUser.

All 3 lookups are READ-only. There is no update or operation at the DB.

All 3 are enabled by a User’s login or a friend’s lookup.

All 3 have the same frequency

Several different schema constructs are needed for this task. Look into the EER diagram and see how big a portion the personal information covers, the educational and the professional education.

Consistency is not critical, even if the profile is being edited by the User, while a Friend is looking at it (woher weiß ich das?)

These can be done in any order, they do not need to be done in the order of personal, tehn education information. There is flexibility in execution.

However, all 3 must be done, so mother task is needed.

Most of the above are good indicators that the task should be decomposed into 3 subtasks.

(1) Personal

The first step is to find the CurrentUser using User Email. Having found that we can display on the output document (screen) Profile.

>> Display UserName

Find the current RegularUser using User Email;

The screen is both input and output that needs to be supported by the Edit Profile task. This is somewhat more complicated than the View Profile task.

The rule of thumb:

• Lookup of Personal, Education, and Professional information of a RegularUser in order to support editing it. We just specified the View Profile task, so we are using that for that.
• In order to populate the Edit Profile screen, it is necessary for us to go to the DB and lookup the list of Schools and the Employer lists, Without those, we would not be able to populate the dropdown menus.

Link (Remember, to not embed the Twitter links, because they will not show up on the Notion/SuperSite)

Link

The idea, again, is that we have the forms that are the interface to the application, and our job is to now talk about the decomposition of the task that are necessary in order to tie these forms through the task into the database.

If we did a closer analysis using the for task decomposition for this task we would arrive at the following result.

The Request Friend task would be separate from the others. This task would update the database with the Request.

The View, Cancel, Accept, Reject Request is the one that supports the “Request New Friend” form. It would end up being decomposed into 2 subtasks

• View the Request. This subtask supports the reading of User, RegularUser and Friendship information.
• Support the Accept, Request, Cancel the Request options. This subtask updates the Friendship.