Categories

## FIT9019: Week 2

We got into the Relational Data Model today in Manoj Kathpalia’s second week lecture. I found this lecture much more interesting and challenging than last weeks which was great. Until now the terminology I had used for Relational Databases was: Table, Column, Row. Today I discovered that the RDBMS industry is engaging in mass duplication of data by having to remember the following alternate names:

• Table – > Relation, Entity
• Column -> Attribute / field
• Row -> Record set / tuple / entry

Why everyone doesn’t just use Table, Column, Row is beyond me… We covered some properties of Relations, Primary, Alternate and Foreign Keys. I was a little confused by the Relation Languages segment where Data Definition Language [DDL] and Data Manipulation Language [DML] were outlined.  Does SQL encompass both DDL and DML? If so why separate them? Further investigation reveals DDL, ‘Initially it referred to a subset of SQL, but is now used in a generic sense to refer to any formal language for describing data or information structures, like XML schemas.‘ source: http://en.wikipedia.org/wiki/Data_Definition_Language … which reminds me that I need to do some learning about XML. DDL -> Create and Delete (DBs, Tables, views, integrity contraints, indexes) DML -> Relational Calculus, Relational Algebra,  Transform Oriented Languages, Graphical Languages (MS Access),  4GL, 5GL  (All exhibit ‘closure ‘ property – whatever you do is not stored permanently and gone on closure of the instance.) For DML we are focusing on Relational Algebra as it is apparently more simplistic. Relational algebra has 8 basic operators:

• Selection
• Projection
• Join
• Union
• Intersection
• Difference
• Cartesian Product
• Division

We went through definitions of these with theoretical examples which I think failed to pull the theory into any relevant practical sense. I hope the tut will give me some more practical connections for this theory otherwise (without a much larger mathematical understanding) this is rote learning without the ability for application. Will update this entry after the tutorial. In the tutorial we went through some clarification of terms and then moved onto some prac questions on Relational Algebra for which I made some notepad notations:

Q4, D

[1] -> (ROOM) |x| ROOM.Hotel-No = HOTEL.Hotel-No (HOTEL)

[2] -> π type,price([1]) PROJECTION

[3] -> Θ [2].Name = Grosvenor ([2])

Q4, e

[1] -> (GUEST) |x| GUEST.Guest-No = BOOKING.Guest-No (BOOKING)

[2] -> ([1]) |x| [1].Hotel-No = HOTEL.Hotel.No (HOTEL)

[3] -> π [2].NAME, [2].ADDRESS ([2])

|x| – JOIN

π – PROJECTION

Θ – SELECTION

note that SELECTION and PROJECTION should be done first if efficiency is a concern.

Working through the Relational Algebra was good as it tied the link between theory and possible practical applications. I know if I had known this theory previously I could have saved time on several projects using SQL databases. Pearl of the Week: Relational Algebra Basic Operators:

• Selection (Slices Tuples)
• Projection (Dices Attributes)
• Join (Natural Join, Left/Right/Full Outer Join, θ-join[uses binary operators {<, ≤, =, >, ≥}]
• Union
• Intersect
• Difference
• Cartesian Product
• Division
• Rename? [(Actually, Codd omitted the rename, but the compelling case for its inclusion was shown by the inventors of ISBL.)source

Categories

## FIT9030: Week 2

The second lecture presented by David Grant for Systems Analysis and design was focused on systems development models, primarily the Systems Development Life Cycle [SDLC]. We did not get through the whole lecture which was not surprising as it was almost 70 power point slides.

Quite interesting that we should cover this topic a week after the company I work with hit the switch on a new system upgrade for 60,000 web and email hosting clients (a chain of revealed bungles ensued with disastrous results). In the wake of confounded clients and postal resellers I can’t help but think it would have been nice if the project manager had checked out this lecture.

We started off with the SDLC as it is the foundation of development models from which most others are founded on:

• P – Planning -> Define business problem and scope, produce schedule, confirm feasability,  POSTEL (investigate: political, operational, schedule, technical, economic and legal as influencing factors for planning.), Resource allocation (staff and funding). Launch date.
• A – Analysis -> Gather more detailed information, Define and prioritize system requirements (get client to sign these!), Build prototypes(using CASE tools),  create and evaluate alternatives, Review with management.
• D – Design -> network, application architecture, Interfaces, database, prototype, system controls.
• I – Implement -> Construct software components (write code), test program, document system, train users, migrate legacy data, install system
• S – Support -> Maintain and enhance the system, support users.

Next came some scheduling models comprising of Waterfall, Overlapping and Iteration of which I perceive  Iterative to be the most applicable to all but the simplest business scenarios. The business environment is much too fluid to imagine a single launch phase.

We then investigated some approaches to system development:

• Structured – Procedural/Process centric
• Information Engineering -Data centric
• Object Oriented – Concept based (I believe this approach is now the most popular with the rise of JAVA). As I have done most of my own programming in using the OO paradigm, the most intuitive for me.

Which brings me to the pearl of the week:

• Information Engineering – A Data Centric approach to system development recognizing that the types of data created by a business is one of its most stable aspects. After hearing about this in the lecture I checked this methodology out on Wikipedia (see here).

I was interested to read that there are several variants and that the creators of this methodology have gone on to create other methodologies including an Object Oriented type. With such a huge number of  methodologies and variants on each of them I understand David’s statement at the beginning of the lecture (which was something like: In practice Systems Analysts don’t actually apply these theories directly, it just helps to be aware of them). As per usual conceptual understanding/comprehension in conjunction with experience is superior to rote learning 150 models and methodologies.

Heading straight to the tutorial again after the lecture was easier this week. This week group presentations were due. We did not commit a great deal of time to preparation for this and I am glad I did not spend any more than I did. Primarily because (although interesting) the presentations were not really focused on the course scope,  secondly, it was not an assessable piece of work and thirdly because we did just as well putting together our ideas over email and adjusting on the day. I agree with Linus Torvalds in his strategy of avoiding meetings and phone calls instead favoring email threads. With email threads everyone gets a turn to speak, everyone has to think before they submit their opinion and repetition is reduced. Email threads > Group meetings.

The whole tut was taken up by group presentations with intermittent additions by David, it was really enjoyable but again, not sure how related to the course it was. I look forward to doing some more practical work in the tuts as this will re-enforce the theoretical topics covered in the lectures.

Categories

## FIT9017: Week 1

A two hour lecture and two hour tut for what I expect to be my favorite subject this semester. Four hours straight from 6pm-10pm is a little tough after 4 hours of straight classes prior. The lecture was presented by Judy Sheard who was a change from the male dominated IT lecturing staff. I was a little disappointed in the opening lecture as it was very remedial, at what I would consider a high school difficulty. I must do this subject as I have had no previous ‘Official’ programming classes.  I would say however that most programmers learn 90% of what they know from self learning and if that doesn’t count as credit then nothing should. Furthermore, I am the one paying for my subjects, if I want to do something more challenging then I should at least have the opportunity to do so. Judy did make a good counter to this however mentioning that the beginning of the subject may seem simple but pay attention as thing become more difficult very quickly, so lets hope she’s right.

The lecture contained administrative start (4th and final time I have to hear it :D) moved onto brief history of computing (again), brief history of programming languages and then an introduction to Java and the Object Oriented Paradigm. It was good revision but honestly, anyone who is doing postgraduate IT studies and had not already learned these basics in their preparation studies is simply not preparing sufficiently.

Luckily I found the tutorial, taken by Michael Smith to allow more independent learning at our own pace. I appreciated Michael’s frankness and self learning teaching style, he seems to take the attitude of facilitating learning for those who want to rather than dictating to the class. Look forward to more tuts in this subject.

Started using BlueJ in the tutorial which at first I thought would be far inferior to netbeans which I currently use (see link on left). I immediately found the benefits of BlueJ when creating an abstract class and a depended class, the visual layout assists with the code writing rather than interrupting it and I am sure this tool will help me fully grasp the concepts and practical implementation of Object Oriented coding.

Pearl of the week:

When writing in Java, the this.attribute notation was always a source of confusion for me… why would anyone use it? I had never needed it. The reason is specifically for when parameter names are the same as attribute names, (something I learned not to do) but a logical explanation for something that seemed quite the opposite to me previously. Thanks Michael.

Categories

## FIT9018: Week 1

The first lecture for Computer Technologies and Operating systems was held today. The format for the subject is a one hour lecture followed by a three hour lab session, something I was happy to learn. Especially after finding that the lab session would be crash courses on a number of practical tasks such as setting up a web server and installing linux distros ect. The lecturer, Andy Cheng, was energetic and able to explain the topics covered in the lecture clearly.

In the lecture we, for the third time this week, went through administration topics (thankfully quickly this time).  Andy went on to discuss some relevant background on computer history, followed by some fundamental computer definitions and diagrams. Things started to get interesting when we got into the definitions of:

• The Bus / Bus controller – lines of for data flow between components (lines one can see on motherboards)
• Fetch/Execute Cycles – Fetch retrieves next instruction from the Program Counter and loads it to in Instruction register, in Execute cycle the Control Unit decodes and executes instructions.
• Interrupts – Tells the CPU to suspend current task to memory and deal with interruption task.
• Multiprogramming – Multiple programs in memory and switching the processor between them using interruptions. Gives the illusion of processing many programs at once.

Unfortunately we ran short on time towards just as we were getting into the explanation of interrupts (damn the administrative crap wasting the first quarter of the lecture).  This subject seems very practical and I look forward to learning many methodologies which I can apply immediately to current projects.

Categories

## FIT9019: Week 1

Started off the semester for Database Technologies with a lecture by Manoj Kathpalia. Although the lecture was slightly unstructured we got through the admin and some basics about the history, uses and concepts of databases. Interesting points were on the evolution of databases from strings to filing cabinets to file based programs to database management systems DBMSs and the current state of relational DBMSs. I was suprised to find that we would be doing most of our coursework on Oracle systems as MySQL or another open source solution would provide the same learning environment but with greater opportunities for extended self learning.

We spent a good deal of time discussing why database processing was advantageous with the key points being:

• Extracting information from data (for decision making)
• Sharing of data
• Standards
• Controlled redundancy
• Integrity control
• Security
• Economies of scale
• Data independence

Each of these points has a number of more practical benefits for organisations.

Some disadvantages of databases primarily as cost and complexity were also raised. Although I have been using mySQL databases for some time I was not aware of the ANSI/SPARC architecture which we covered next which defined the External, Conceptual and Internal levels of modern database structure.

Pearl of the week:

The Database industry is the second largest of the IT sector, topped only by Operating systems, with over US\$15 billion per year of revenues. MySQL was also not mentioned in the top DBMSs (a point that will surely change assuming Oracles purchase of Sun does not derail the c0mmunity driven project).

It will be nice to get some theoretical understanding to back up the practical experience I have had with databases, I am sure the theoretical understanding will have large influence on the way I think about and execute database design and management in the future.

Categories

## FIT9030: Week 1

Started the semester with a Systems Analysis and Design double, 2 hour lecture followed by a 2 hour tutorial, both taught by David Grant. First of all congratulations to David for holding everyone’s attention for 4 straight hours which is a mean feat in itself. A colourful teaching style with interesting analogies kept the class listening and involved.

As with most introductory classes their was a lot of non-subject specific items covered however a structured preview of the course along the reasons why we should learn the material has set a good foundation for the coming classes. Having the class material up on Moodle very early (in comparison to other subjects) allowed me to preview the lecture and tut which is basically a must. This begs the question why other subject coordinators haven’t done the same.

The tutorial was interesting with the usual self introduction rounds. The following activities and homework assignment, a broad analysis of some large systems, seem a fairly indirect avenue to explaining some basic principles of systems. I guess the broad stroked approach is designed to spark interest in as many students as possible. Although one should already be interested enough if one has chosen to do a post graduate course on the topic.

Pearl of the week (Taken from FIT9030, Sem 1, 2010, Lecture 1):

Analyst’s approach to Problem Solving

• Research and Understand the Problem
• Verify the benefits of solving the problem outweigh the costs
• Define the requirements for solving the problem
• Develop a set of of possible solutions
• Decide which solution is best and make a recommendation
• Define details of chosen solution
• Implement the solution
• Monitor to ensure desired results are achieved

Although the acronym ‘RVDDDDIM’ may lack catchy-ness, this process has clearly come from practical experience and I can make easy relations from the theory to real-world. Thanks David.