“Graphical representation of the data requirements of a database”
After speaking with lecturers I decided that the next element to set about creating for the artefact hand in would be the database from which I will be working. Whether my project changed or altered as I continued the work remains to be seen but databases are generally integral to many pieces of work so it is important that I understand the processes which go into creating one.
I was instructed to look at entity relationship modelling as the first step as this would allow me to learn the fundamentals and also greatly speed up the actual creation of the databases if I had a good structure on which to build. Folksonomy provided and good beginning to this, I found a short instructional video which helped me brush up on what I had learned (having not had a chance to review ERD in a few months). This I will follow with the more in-depth look at it from Frankie Inguanez before designing a prototype data base with some planning help from a lecturer Simon Perkins. After this I will follow some more tutorials curtesy of Lynda.com to help refine and master the ERD before again using Lynda.com to help me create the actual database.
The video while great for someone only really starting to learn ERD did go through a number of the concepts very quickly with little explanation on how they should be created (specifically composite keys) but it did outline the basics very well while also demonstrating how it should be used in a real world scenario.
(EDIT)After reading the YouTube comets on the original post it becomes apparent that there may be one or two mistakes in the tutorial, (but these are youtube video comments) and I still found it useful as a starting point.
Five key elements from the video (Almost word for word)
Entity – represents a person, place or thing you wish to track in a database, This will become a table in the database. Each occurrence of this entity is an entity instance, this will become each record or row in the table.
Attributes – describe various characteristics of an individual entity. These will be the columns in the table, these don’t have to be unique. E.g. first name
Primary Key/identifier – an attribute or group of attributes that uniquely identifies an instance of an entity. This must be unique, as it is used to identify the entity instance. E.g. student number. Sometimes you need more than one attribute to make an instance unique, that’s when you use a composite key
Relationship – describe how one or more entities interact (a verb) with each other. E.g. this entity has a phone number. Essentially a line showing the relationship exists.
Cardinality – the count of instances that are allowed or are necessary between entity relationships. How many rows we need from one table to link it to another table. Showed with crows feet notation. Broken into two parts minimum(fewest rows needed for a relationship)/maximum(cannot exceed a number of rows for the relationship)
The whole Entity Relationship Diagram is designed to act as a blue print for the database.