Class 1 | Week 2 | DAT601

Todd started his lecture off by getting the point across that the ER diagram is supposed to understood by those not savvy to database terminology and symbols.

Upon Todd going in depth about entities, the different types of attributes and keys I have not fully come to grip with understanding it all but I can feel the cogs turning in my brain upon his explanation of a variety of  real world examples.

 Todd glanced over some familiar concepts but some new stuff as well, the stuff that is sticking out to me that I will need to come to understand will be the different types of attributes as well as different types of keys. Along with this there are a couple new words that I have also popped up within my class notes.

Cardinality is still a familiar concept from last years classes so this was easy to understand as he spoke about it, still yet to see if Todd will go into more depth on this although I'm not sure if its something that can offer much more depth considering its simplistic nature.





 Class notes
ER Model

Entity | it is a real world item

Entity set | collection of entities of a particular entity type in a database at any point of time is called an entity set
                entity set is usually referred to by same name as the entity type

Attribute | attributes are the properties that describe the entities
                attribute names are enclosed by ovals and connected to their entities by single line
                set of attribute values of a given attribute is the value set or domains


Attribute types 

Simple | 

cannot be split into further attributes
also knows as stomic
e.g SSN

Composite | 
can be divided in to smaller subparts which represent more basic attributes with independent meaning
even form hierarchy
e.g address

single valued attribute | 
attributes having single value for particular entity 
e.g AGE

multi valued attribute | 
attribute having set of values
denoted by double circled oval
phone number, college degree

derived attribute |
attribute valued are derived from another attribute
denoted by dotted oval
e.g AGE

stored attribute | 
attributes from which the valued of other attributes are derived
e.g birth date


identifier attribute or key attribute |

key: data item that allows us to uniquely identify individual occurrences or an entity type 

superkey: attribute or set of attributes that uniquely identify a tuple

candidate key: minimal super key with the properly of irreducibility and uniqueness

primary key: an entity type may have one or more possible candidate keys, the one which is selected as primary key

composite key: candidate key that consisting of two or more attributes

foreign key: an attribute or set of attribute that matched the candidate key or other or same relation


Criteria for selecting identifiers

some entities have more than one candidate identifier, so the following criteria should be used:

    choose identifier that will not change in value over the life of each instance of the entity type

    choose identifier that is guaranteed to have valid values and will not be null ( or unknown). If composite,                                         make sure all parts will have valid valued 



Avoid the use of intelligent identifiers whose structure indicates classifications, location or people that might change. e.g. the first two digits of an identifier may indicate a warehouse location, but suck codes are often changed as conditions change, which renders them invalid.



Relationship type

don't model foreign keys in relationship diagram, these are instead modeled in the relationships themselves, visually

when attribute of an entity refers to another entity type there exists relationship

Ex: attribute 'Manager' of DEPARTMENT referred to another employee who manages the department that controls the project

attribute 'Controlling-dept' referred to another???

in ER diagram these references must be represented as relationship and not attributes.

the relationship or often denoted by a diamond and uses verbs


degrees or relationships

binary | two entities
ternary | three entities
quaternary(n-rry) | 4 entities

unary(recursive) | it is a relationship where the same entity participates more than once in different roles.
                            in the example above we are saying that employees are supervised by employees.


Cardinality constraints

one to one
one to many
many to many




    






Comments

Post a Comment

Popular posts from this blog

Class 2 | Week 9 | DAT601

Today's lesson pertains to more SQL language beginning with the GROUP by clauses, little examples are being shown on the projector for us, these kind of physical examples are a lot easier to digest than writing on the whiteboard. Group by must appear after the FROM and WHERE clauses, GROUP by groups rows into subgroups based on values of columns or expressions. Todd's example is used to group columns together to show a sum of total sales for a specific region. Another example of a group by rollup which is described as a niche function which caused some debate in class as to what it actually does. GROUP BY GROUPING SETS is used to allow multiple group-by clauses to operate in a single statement, GROUP BY GROUPING SETS is equivalent to the 'union' of two or more GROUP BY operation in the same result set. Next topic is Views within SQL, which is used to present the information data in a different point of view. This can simplify the access to specific information w...
Read more

Class 2 | Week 2 | DAT601

Image
Beginning this weeks second class Todd has provided an example document for our milestone one and is walking through it to help us understand the different types of tables he desires. Upon learning that this milestone is about 15 pages max I am feeling comfortable. After this he has continued with last weeks power point and explaining more conceptual database concepts in depth, including but not limited to: cardinality, weak vs strong entities, multiplicity constraints and so on. Below is some pictures from my teams brainstorming over our teams conceptual design done earlier today, nothing perfect but getting together to do this ignited some interesting conversation and I felt like we made progress in the end. Below are my class notes for today Cardinality     cardinality is the count of entities within the relationship Participation     specifies minimum number of relationship instances each entity can participate in     this is cal...
Read more

Class 1 | Week 14 | DAT601

Today's lesson pertained to an explanation of the Milestone three steps to get everyone on the same page before Todd started into a talk about database file structures and the different structures they may take. The following discussion resulted in a lot of in-depth information regarding storage sizes that is ideally relevant to the estimation of database storage size task we have to complete within milestone 3. The rest of the class has been assigned to milestone 3 work.
Read more