Information Systems and Databases

Data. What is Data? Is it just information made up from 1s and 0s. Or is it something deeper. Are there things in data? Or is data in things. Can you quantify life? Can you put life into a table, in a database, on a server somewhere, for randoms to access on the internet? If you could put life into a database, could you manipulate it with relation algebra. Could you select the strongest parts of one life and the smartest parts of another and create a cartesian product of them? Could you join her joy with his charm? Could you difference out the hate of man and lock it away? Could you union people’s ideas and make them see the big picture? The big picture of big data.
Though what we covered in my first ISD lecture did not answer these questions, it has still got me incredibly intrigued and fascinated. In the first half of the lecture, we went through the module structure, then we looked into the theory of the database environment. We explored some of the history of databases, showing how we got to the three-level database architecture. For the last half of our lecture, we learnt about the relational model and set theory. We were given information on the structure and behaviour of a relation, and how to manipulate a relation with relational algebra.

Data. Data. Data. Well, more accurately, data modelling. Data modelling using something called an ER diagram. Oml why can’t I remember what ER stands for… God this is annoying me. What was it? Empathy realisation… No. Eternal reconciliation… No. Ethanol recall… Oh wow, no where near. Oh yeah. Entity Relationships. This it! Entity relationship modelling is one of those things that seems simple with a small amount of exposer, but it quickly becomes much more complicated. For example, five entities with 7 different relationships isn’t too bad. But let’s say you had twice as many entities. That does not mean that you will have twice as many relationships. Oh no, no, no. It’s not that easy. The relationships can go up exponentially with the increase in entities. So, now you might have 10 entities with 25 different relationships. Conversely, you could have a model that has many entities with very few relationship and in that case, you would not want to overcomplicate the model by adding unnecessary relationships.
Jeez. I’ve got a headache.
This should be fun :)

Liz had a microphone today. That was good. Until it broke and we couldn’t hear anything AGAIN! She was halfway through explaining normalisation, and then… nothing. She didn’t realise for a few seconds that it had broken, until someone shouted out. “We can’t hear you!”. I think the batteries must have died. Oh well. Anyways. Normalisation, that’s what we are talking about. Okay so basically, relations have different normal forms… Like 1st normal form, 2nd, and 3rd normal forms. When a relation is in a normal form it pretty much means that a relation follows curtain standards. Like if a relation is in 1st normal form, then it doesn’t have any duplicate entries. It only gets more complex from there, and it goes all the way up to 6th normal form. It’s interesting because normalisation is a bottom-up framework for regulating relations. I much prefer using it over entity relationship modelling.
Oh also, we have a test on this stuff in like two weeks. And honestly, I’m a bit concerned. I’ve really got to make sure I study up on this stuff. Otherwise, it’s most certainly not going to go well.

I hate exams. They just suck. They make no sense. You learn something for a number of weeks. Then you regurgitate it once and you’re given a grade. After that, you just forget it. They make no sense because revision is not the best way to learn. Conversation is. When you revise for a test, you don’t think. All you’re trying to do is remember. But when you talk to someone about a subject, and they respond, you actually have to think about it. This allows you to think and retain information. But at the same time, I do understand why we have tests. When you have a lot of people to assess quickly, tests are sometimes the only realistic way to do it. So, I will play the game, put in the work, and try my absolute best.
We have a test next week. The test is about relational algebra, entity relationship modelling, and normalisation. I’m pretty confident in normalisation, kind of confident in ER modelling and relational algebra just isn’t that difficult. Thankfully, in this lecture we were revising it and I was getting most of it. Wish me luck for next week.

Okay my opinions on tests have changed slightly. CAUSE THIS GUY GOT A 100%! I know I said some mean things about exams last week, but I suppose that’s just what losers do. They complain about what they can’t win at. But no longer. Cos, I got 100% in a test about relational algebra, ER diagrams, and normalisation. Lemme just say that one more time. I got 100%. Okay, okay, I’m going to stop bragging now. In all honestly, I am quite proud of myself. I wasn’t too sure of my knowledge in the subjects but I’m more confident now. Evidently ha-ha. Either way, we still had a lecture. It was about SQL queries and statements such as ‘select’ and its clauses. That was interesting. In other news, our group project has been cancelled because there are 501 students and one lecturer in this module. So, it’s kind of difficult to get everyone organised and then mark all the reports. Instead, we are probably going to have more tests and maybe a smaller assignment. Which I’m not too bothered about.
All in all, I think I’m going to enjoy this module.

We didn’t have Liz today. Not sure if she was ill or what but anyway, we had Hafiz instead. What a legend for real. He was teaching us about some more SQL select clauses, such as the ‘where’ clause. We also looked at string functions, some miscellaneous functions, and date and time functions. All in all, it was again not super complicated. Very interesting stuff though. I’m understanding more and more how you would use certain queries to display information in a user-friendly way. For example, you can concatenate a first name field and a surname field, so they read as one.
Looking forward to next week.

Oh, come on Liz make your mind up please! Guess what. The group project is back on. But don’t worry, we aren’t assigned random groups. We can choose our own. This is great but for some reason, people in my group (i.e. my friends) haven’t been showing up to the lectures. Why haven’t they been showing up to the lectures you ask? Well, for this and that, or can’t be asked, or trains are cancelled. Stuff just seems to get in the way. I’m hoping that as we go into the project people will become a bit more motivated about it and start coming into Uni more consistently.
In the project we have to design and build a relational database using a set requirement. So, we have to make the ER diagram, build the actual database with Oracle APEX and code the SQL functions necessary for a user to access the data. And we have to document it all. Better get cracking aye.

Joins in SQL are where you have two tables in a database and you want to join the information together for some purpose. Whether it be for ease of the end user or to perform a specific operation, you could use a join. There are different types of joins, such as an equi-join, a non equi-join, an outer join, full, right and, left outer joins and a few others. They are pretty useful. However, I’m finding it slightly difficult to wrap my head around translating a question into an actual query. For example, “Create a list of all the descriptions of products ordered by the customer ‘SMITH’”. I get what they are wanting as an output but I’m not too sure how to go about it. This is how you would do it:

• SELECT name, descrip
• FROM customer JOIN ord USING (custid)
  • JOIN item USING (ordid)
  • JOIN product USING (prodid)
• WHERE name = ‘BROWN J’;

Evidently, I need to practice more. I’ll get on that this week.

For this lecture we looked into how to create, modify, and delete tables in SQL. This information is super useful for our database project. Specifically, for the table creation scripts element of our project.
We also looked into the database life cycle which has 6 stages:

1. Database initial study
   1. Analysis of the requirements
2. Database design – 3 stages:
   1. Conceptual design
      1. The process of constructing a model of the information that will be used in the database, independent of physical considerations.
   2. Logical design
      1. The process of constructing a data model that is independent of any specific DBMS.
   3. Physical design
      1. The process of constructing a data model for a specific DBMS (For example, Oracle APEX).
3. Implementation
   1. Creating the database in the specified DBMS.
4. Testing and evaluation
   1. Testing and fine-tuning the database.
5. Operation
   1. The point at which the database is in operation and may need design changes due to unforeseen problems.
6. Maintenance
   1. The ongoing process of updating/modifying the database so that it continues to meet the ever-changing requirements.

This is the last ISDB lecture for the next two weeks as there are two concurrent bank holiday Mondays. Talking about concurrent things. Today in the lecture we were learning about concurrency control and transaction management in relation to databases. Concurrency control means how access is managed when multiple people are using the same database at the same time. It is concerned with maintaining consistency within a multi-user environment. Transaction management helps this process by grouping commands into logical units of work. For example, someone placing an order would require a number of commands on the database. Inserting the order, updating the customers owing balance, and updating the stock. These three elements are one transaction (a logical unit of work). Once the transaction is finished it can be committed to the database. The system needs to ensure that either the transaction is completed in its entirety, or it is not completed at all.