Categories
Database Technology

FIT9019: Week 3

Week 3’s lecture by Manoj Kathpalia got into database design. We continued our referencing to the ANSI/SPARC architecture which it appears will be an ongoing theme.

The lecture ran through the Database Design Cycle introducing Requirements Definition, Conceptual Design, Logical Design and Physical Design. With detailed analysis of ER modeling which applies to Conceptual and and Logical Design (which are both at the conceptual level of the ANSI/SPARC architecture).

I have some confusion over Cardinality, I assume the  Cardinality of Relation and the Cardinality of a Relationship are two different things. The cardinality of a relation being the number of tuples and the cardinality of a relationship being either 1:1, 1:M or M:N. I will need to clarify this with Manoj.

The ER model is quite a simple graphical modeling tool which we review in the tutorial, it does however seem that there are a number of acceptable notations in ER modeling some of which can be seen here.

Pearl of the week:

Although ER modeling can be used for both Conceptual and Logical Design, the Conceptual Level does not include Foreign Keys and allows Many-to-Many relationships.

After working through the ER model, we touched on integrity constraints, specifically Referential Integrity constraints:

  • Foreign Key references must be valid or null
  • Update Rules either restricted, cascaded or null (ie: when the customer_ID is updated in the customer table, the foreign key in the order table can either stay the same, update or become null).
  • Deletion Rules either restricted, cascaded or null (ie: when the customer_ID is attempted to be deleted in the customer table, it can either be restricted (forbidden delete), delete the associated orders :O or set the customer_ID filed of the order to null).

Finally we covered an introduction to Database Design Language [DBDL]. We did some more work on DBDL in the tutorial although there were some discrepancies between the lecture example and the tut examples (ie including CK and PK). From the final question of the tutorial, my derived relations in DBDL were as follows:

book(ISBN, call_num, title, pub_date, publisher_ID)
SK title
AK call_num

author(author_ID, surname, first_name, DOB, initials)
SK surname
 SK initials

author_book(ISBN, author_ID)
FK ISBN -> book - Delete restrict, Update Restrict
FK author_ID -> author Delete restrict, Update Restrict

subject (sub_name)

subject_book (ISBN, sub_name)
FK ISBN -> book - Delete restrict, Update restrict
FK sub_name -> subject - Delete restrict, Update Restrict

publisher (publisher_ID, pub_name, street_add, city, postcode, country)
AK pub_name
SK pub_name

I did not include CK and PK as they were not included in the lecture’s example.

Categories
Systems Analysis and Design

FIT9030: Week 3

Another packed lecture from David grant for Systems Analysis and Design yesterday. The first half was a completion of last weeks unfinished lecture on Systems development methodologies. We had a more in depth look at the Object Oriented Approach and its associated methodologies, primarily iterative/spiral which is the current trend. Extreme Programming, The Unified Process and Agile Modeling (a hybrid of the two former) came next. I had not realized previously that my work place utilizes Agile Modeling with SCRUMs and SPRINTs, another timely point that related directly to my job came about when David mentioned that the Agile model would only be successful with experienced, self managing developers (haha … :|). From this lecture I became a little more confused on the distinction between models and methodologies. I recall David mentioning something on the differences but that has escaped me and when looking at wikipedia’s explanation (wiki link) it appears that they are basically substitutable terms;

The framework of a software development methodology consists of:
* A software development philosophy, with the approach or approaches of the software development process
* Multiple tools, models and methods, to assist in the software development process.

I have found the lecture and course work structure very good for this subject as it uses a consistent process; Introduction of broad concept -> Introduction of Practices -> Analysis of Practices which feels to me like conceptual clustering.
conceptual clustering

Speaking of which, following the introduction to Extreme Programming, The Unified Process and AGILE modeling, we looked at them in further detail:

Pearl of the week –  Object Oriented Methodologies

  • Extreme Programming – Lightweight, efficient development process, utilizing informal stories and programming pairs. This methodology relies on heavy user involvement and continuous testing and integration.
  • Unified Process – Object Oriented, uses UML, based on (but labels 4 phases) of SDLC and Reinforces six best practices
  • Agile Modeling –  Hybrid of XP and UP, uses Interactive and Incremental modeling. Really a logical evolution of  XP and UP based on practical feedback.

The mysterious CASE tools,where introduced again in this lecture but again not covered in detail. I imagine this is because we need to understand all of the concepts in detail before using the tools but by mentioning them the topic it will not feel entirely new when we get onto it.

We completed the previous weeks lecture back on the SDLC getting some revision on the first of the 6 phases [PADIS], Planning.

Steps of the Planning phase

  • Defining the Problem
  • Confirming Feasibility [POSTEL]
  • Launching the Project

The current weeks lecture was a bit shorter and focused on phase 2 of the SDLC [PADIS], Analysis and Requirements Gathering. The key outcome of which was how System Requirements should be compiled; through review of documentation, interview, observation, prototypes, questionnaires, vendor research and joing application design sessions. Most of the Analysis phase is quite intuitive:

  • Gather information
  • Define System Requirements
  • Prioritize System Requirements
  • Prototype for feasibility and discovery
  • generate and evaluate alternatives

Also mentioned in the lecture was Business Process Re-engineering however this practice is now becoming more modular and should be driven by the business management (although a systems analyst would provide suggestions or plant seeds as the case may be).

In the tutorial we spent about 35 minutes on the Malcolm Gladwell talk, but the points where valid concluding that Systems design must pay great mind to humanistic aspects and influences.

We will start our assignments next week which should further reinforce what we have covered thus far.

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle#Requirements_gathering_and_analysishttp://en.wikipedia.org/wiki/Systems_Development_Life_Cycle#Requirements_gathering_and_analysis