Wednesday, April 29, 2015

Database design. Day 3, what Iv learned


Access 2013 tutorial


By watching the Access 2013 tutorial, I was able to learn new elements of the program.  Two simple elements I learned first before moving onto cardinalities was that you can simply delete a row of a table by selecting the “Delete Row” button, and you always want to make sure you are consistent with your database.  If you spell something wrong, an error message will appear, which helps you keep everything consistent.  To move onto cardinalities you can choose the relationship button, which is the relationship between tables.  The tutorial used movies as its example.  You can create a separate table that links the movie table and genre table together. The primary keys from the separate tables are linked and become foreign keys in the new table.   To actually link the tables together you then have to change the data type of the attribute to “long integer”.  Then with your set of tables, grab the ID from your movie table with your mouse and drag it on top of the text “movie” in the new table.  By doing this step, it create the relationship between tables.  Next, a box will appear where you have to write down your properties.  Click “enforce referential integrity” to create the link. This will then show the one-to-many link with a dark line and crow’s feet.  After that, you want to repeat the same process for the genre table.  After watching this tutorial, I know now how to create cardinality graphs on Access 2013.  


Unified Modeling Language UML

A popular system used in the database world is called the unified modeling language (UML), which can be graphical and can be translated into relationships automatically. There are 5 concepts of UML: Classes, associations, Association Classes, subclasses, and composition & aggregate.  Class consists of name, attributes, and methods of the class.  When data modeling just add Pk (primary key) and drop methods.  Multiplicity of associations are relationships between objects of two classes.  The types of relationships are one to one, many to one, and many to many, but in this video we learn a new type; complete.  Complete is when every object must participate in the relationship; it is always one to something, no 0's.  Association class is additional information that is related to the two classes in the relationship.  The video gives us an example of student related to college, which its association class is application info of that student applying to that certain college.  The association class is created below the student-college relationship.  The video explains that you cant have in UML is having more than one association between the same student and the same college.  Self association is just an association between class and self; for example, you and your sibling. The video moves on to talk about subclasses.  Subclasses are extensions of the superclass.  A super class is a generalization while a subclass is a specialization of that superclass.  For example, Student is a super class while  while domestic, foreign, and AP students are it's subclasses.  Here I learned that the superclass relationship is complete if every object is in at least one subclass.  It is incomplete if this is not true.  I also learned that the superclass is disjoint if every object is in most subclasses and it is considered overlapping is objects are in multiple subclasses.  Next in the video, it talks about composition which means that objects of one class belong to objects of another class. This is shown by a colored-in diamond on the relationship line.  Aggregation means that the class can be related to the other class, but doesn't have to.   Aggregation is shown by an empty diamond.


Physical vs. logical data models

Since this was a short video I didn't learn as much as the other two, I did learn about logical and physical data models.  Logical data models are general depiction of data which show entities and relationships, whereas physical data models show enough detail to depict how the database is built.  For example, details can show if the key is primary of foreign.  When going from the physical model to relational model, there are some terms that will change.  An entity becomes a table, an attribute becomes a column/field, and an entity instance becomes a row.






No comments:

Post a Comment