Unlike when we are planning the database the physical database is limited to how it is stored and the size of the database is not exact. This is because data tables up ‘pages’ and if a page is used than all of that page is reserved even if it is not fully complete.

This also helps us to see how many null values we have in the database.

Transaction take time even if its not much time if the calculation is repeat over and over again time will be wasted. This is why it is important to calculate transactions time. If we find that the time is to great we might need to use join statements or add a secondary index to make the data easier to find.

The stage which normally comes after the logical design is the physical one. During the physical design we take into account the environment we are building the database for this includes things like correct datatype, what the specific SQL language can do for example nulls and feign keys.

The physical design can also involve rolling back some of the changes we made to during the previous stages to either save space or reduce complexity.

In Milestone three I was important for me to convert my database into a physical form as it was already to complicated to beginning with and needed to to have the number of tables reduced.

I manages to de normalizes some of the table with out effecting to much of the databases functionality.

This week we work with Vsphere to set up for our projects.

I have used Vsphere a lot so I didn’t have any problems setting it up. Vsphere is slow, like it always is but it’s easier to use than installing SQL sever on every computer I own and finding a lan cord.

I can’t wait to start working with SQL.

I an slightly worried about having issues with connectors in Vsphere as I very often had issues with the connectors between computers becoming disconnected when I was working with it. This probably wont be a problem because it was set up by someone who knows what they are doing.

Unlike when I was working with Vsphere the computers don’t seem to shut down after a certain amount of time. This is useful as I can leave my work and come back to the same place.

Sorry I didn’t have a lot to write this week.

This weeks class we went over the next assessment. During this time we brainstormed possible entitles and attributes.

This brief seems to be a lot larger than the the previous assessment. This could be because this assessments is a lot more open ended than the first, if this is the case I am probably over complicating it.

One of the big parts of this assessment will be working out the business rules early on in the assessment. In the practice milestone we didn’t complete the business rules early enough, this lead to many changes in the design. I would like to avoid this this time around.

Databox
	ID
	Longitude
	Environmental Configuration
	Latitude
	Temperature
	Humidity
	Ambient light strength
	Orientation
	GPS
Part
	Manufacturer
	Maintenance Date
	Distributor
Maintenance Record
	Mechanic
	Date
	Description
Contract
	ID
Video
	Type
Stream
	ID
Zone
	Name
Subscription
	Fee(Base price, discount, total price)
	Subscription Date
	Contact Details
	Address
	Organization Name
Platinum Subscription
Super Subscription
Staff
Sales person
	ID
Administrative Executive role

Currently I have subscribers as their own table but it might be possible to reduce the number of table depending on what business this brief has.

I think it is interesting how the databases also has has a table for their parts and then their parts have records of maintenance. To me this wouldn’t be the sort of this I would think of if I wasn’t given a prompt.

One business rule which was mention is how the ‘3D Video Live steams’ always has a complete view of it’s surrounding but only certain subscribers can move these live streams.

During this time we work as a group to complete our first assessment. At this point we have move directly to Microsoft teams to better manage our files, we still use Facebook to organize our meeting.

To manage our work we have assigned one team member to manage a single word document which contains all of our work, the other group member post individual documents. This prevents work from being over written.

Currently I have been working on the written discussion for our conceptual ERD though the process I have found a few issues with the ERD this lead to some small changes to the entire project. As previously mentioned we could have avoided this by completing our business rules first.

Additionally I found a few things in our design which were not wrong but in the future I would do different.

He we have chosen to to have items be singular but I would prefer to have items be many to many as it would allow us to reuse the same items over and over. In our design this could have implications. For example it could mean that a character couldn’t pick up two of the same item.

For thw first class this week we discussed how to convert to a logical ERD.

Some of the rules for this conversion are. Attributes stay the same but compisite attribute are broken down into seperate attributes. The main different is that entites look different.

Some of the relationship in our diagram have to change. And our cadadate keys get put though some more criteria to check if they will work. One to One relationships get to remain the same and the foreign key gets put in either table. One to Many relation ships get the key place in the many side of the diagram. Many To Many have a new entite place in between the two table to properly relate them. Multi valued and specialisations get extended into their own classes which relate back to the origionals.

Additionally any relationship with attributes must ever become tables or if approprate have the attributes moved.

The diagram now uses crows foot which is the diagraming style that I am most use too. Crows foot uses a 3 pronged foot to represent a many relationship. A one pronged foot to represent a one relationship and a 0 or 1 to represnet optionality.

For the second class this week we have been looking at normalisation which is something we have to do before we create our data dictonary. The purpose of normalisation to move data in a way which makes it easier to work with. By sepeating attributes into table which logical corolation.

Their are many different levels of normalisation but for this class we have go Boycost normal form which is half way between third and forth normal form.

1NF requires us to identify the primary key as well as any data which seems to be compisite or multivalued. This data is normalised.

2NF We remove any pasical depedencies. A pasical dependence is an attribute which does not directly relate to the primary key. These dependecies should be moved to their own table.

3NF is when we remove any transitive dependencies. A transitive dendency is when on attribute relates to another though a non-primary key attribute.

For the first class for this week we learnt about how to represent specialization on our ERD diagrams.

There are different types of specialization. These are represented by both o and d. D stands for disjointed and O stands for overlapping. A disjointed specialization means that a object can only be one or the other. While overlapping specialization can be both.

For our project the we have one specialization for each type.

The relation ship between the different types of tiles is disjointed as a tile must be either a home tile or a game tile but can’t be both. This is the opposite for users as a user must be either a player or and administrator but a user can also be both. Their is also the option where a type of object can be specialize but doesn’t need to be.

For the second class this week we looked into common problems which occurs with ERDs. These problems take on two forms a chasm which means that one table can’t reach another table even thought this would be useful.

The other type of issue is a fan trap which is when one attribute relates to many other attributes but those attributes don’t relate to each other.

Both errors can be fixed by adding a relationship between the to entities. In our diagram I have had to add an additional entities to better allow data to flow around our database.

This relation ship is important because I allows us to manage wither or not a player is actively playing the game or if they are just on the menu.

Our group still does understand the game concept as such we ended up playing a game with paper so every one know what is going on. Because of this game we figured out the game doesn’t currently work properly because of the map shape. This has lead to changes to the map but not to the ERD diagram. Hopefully storyboards we will all be on the same page.

It now occurs to me that taking pictures of this mock game would have made for good storyboards.

In today class we discussed how to represent relationships in Chen’s notation. For Chen’s notation we represent optionality with a double lined relationship. This means that the indicated entities is a week entities which can’t exist without the other entities. It is also possible for two entities to rely on each other. This is similar to what I have started implementing into our team exise. I need to be represent this though as I have only represented these relationships with a double line but not the double shape.

The one part of this which I was unsure of is when showing optionality the double lines also extend to the shapes which are used.

For our group work I went ahead and created most of an ERD for the project. As we didn’t have a project at the time we have had to make some changes, because we had a brief these changes are to extensive. It took us some time to come up with our project idea because are group has changed a few times and many of the group members have been sick.

In the end we decided on a simplistic plan which focuses directly on for-filing the brief. I think this is the best idea because my design for DAT602 last year was more trouble than it was worth.

Moving forward we need to finish creating a written definition for our project so we can check our ERD diagram. After we are sure that the diagram is correct we can start on our data dictionary.

Update on candidate keys. A candidate key is possible key which could possible become a primary key. A good candidate key is a key which is naturally existing and not created. Like all primary keys they need to be unique. Other things which make a good candidate key is made form the lest amount of attributes possible. A key should not change over time.

Entities sets are name after signaler values similar to OO classes.

Simple Attributes are similar to what I am use too, they are single attribute, where a composite attribute is made up of multiple attributes, this is something which I am not use too. A Single value attribute has a single attribute, single value attributes have to have a domain. A multi attributed has multiple values applied to it.

Super Keys are like candidate keys except that they haven’t been simplified down to it’s candidate form.

Cardinality is a simple idea which I have used several times. Cardinality is how many of one entities relates to another entities.

In conceptional modeling instead of recursive relationships. We should display this with a relationship instead of a attribute.

My understanding of a data dictionary is a table which manages the data in a database. The data dictionary is a reference tool which has information on the data in a database. This allows us to have a single place to refer to to keep everything consistent. (ScienceDirect Topics. (n.d.).)

The flow of database development: Conceptual > Logical > Physical. This year we are once again working with relationship based data-basing. A Conceptual model models relationships basied on

We discussed some basic information gathering techniques which are what I have learnt in SYD601 and will hopefully expand on in SYD701. With this Todd also mentioned UML which we wont be using this year but it should be kept in mind as these server similar use.

A good primary key is something which is unqie and is applied to all entities of a table.

Binary, Unary and Ternary are the different types of relationship ——–Fill in later————-.

Sometimes an object that we identify are an attribute of another object, this is similar to how in last class we had some identified nouns which were aspect of other object such as password and email were part of account. Similar Todd briefly covered generation and specification which allow us to have special versions of some date, I don’t quite understand this so I will need to do some more research but I think it’s similar to how last lesson we had specification like home tile or administrator account.

A domain is a set of data which an attribute can pool a value from, for example in my SDV602 project a character could only select attributes from a specific list of data. It can also be something like like how a primary key can be something like N1 for the first nelson branch or a company. This however wont be a good key candidate as it could be changed and doesn’t model reality properly. This is an interesting concept as I would have assumed this was a good key and it’s the sort of thing I will used.

Candidate key, are an interesting concept I will need to look in to them more, there is a good amount of information in the course topic. I should also look more onto week and strong relationships. A week entities is something which is completely reliant on another entity. Something which exists on it’s own is a strong entity.

I haven’t cover information in this journal the I feel I already know as this journal is already very long. Some examples of information I have left out is things such are cardinality and multiplicity as well as basic modeling notation such as a entity being in a squire. The one thing I didn’t realize is conceptual modeling uses n to m too display many to many.

Data Dictionary—An overview | ScienceDirect Topics. (n.d.). Retrieved February 28, 2020, from https://www.sciencedirect.com/topics/computer-science/data-dictionary

This class focus on the use of database with people in mind.

The coarse will be designed in a way were we can learn theory though practical activity. This means that the coarse is a project based practical coarse. We will be using SQL server for the coarse.

Database design is important for businesses as it allows them to turn data into useful information. Though out this coarse we will use various techniques which will allow us to better model and plan databases. At the end of the coarse we will use SQL to implement a database on a plane.

We will be using relational database as no SQL database have a tendency to be less than practical.

In this class we discussed basics of database design in this class, which are what we went over last year.

The conceptional modeling we are meant to be using in this class is meant to be more complicated. We are using Peter Chen’s entity relational database modeling. Keys don’t exist in this type of modeling, as they instead use relationships. Todd compared this method to a game, where you learn rules which you can applies.

When creating databases we want to be able to reuse the database between different programs. This is called database independence.

We discussed how to transnational database design and work with recovery. We discussed how SQL is one of the only declarative languages in the world were we tell the system what we want instead of what we want to do. This is similar to what we learnt in DAT602.

When discussing what is expected of us Todd mentioned data dictionary which is a term which I recognizes but don’t quite remember so I will need to go over this this before Friday.

We will be going to 5thed normal form which is two steps father than I am use to.