Presentation is loading. Please wait.

Presentation is loading. Please wait.

Class 9: Database Management Systems July 21 st, 2011.

Similar presentations


Presentation on theme: "Class 9: Database Management Systems July 21 st, 2011."— Presentation transcript:

1 Class 9: Database Management Systems July 21 st, 2011

2

3  Looks great!  Google analytics… now what?  I want you to check Google analytics and see who is visiting your Web site.  At the end of the semester, we’ll see who has the most visitors!  How do I get people to my site: see SEO slides; submit to Google, yahoo.

4  Visio stencil on my Web site for ER diagrams

5  List a few current events in information systems news  Construct and ER diagram (Recap)  Use vLookup in excel to mimic a relational database  Convert an ER diagram to a relational database scheme

6

7  Twinkle Tones School of Music provides private lessons only by musician request. When a musician requests a private lesson, the School finds an available instructor and arranges a lesson schedule.  The School would like to track these lessons – the day of the week when they are scheduled, as well as the time they begin.  The School would also like to track musician names and email addresses, as well as instructor names and email addresses.

8 INSTRUCTORSMusicians teach LESSONS MusID MusName MusEmail InsID InsEmail InsName TimeDay [0:M] [1:1]

9 TEAMS Aggregate STUDENTSTEACHERS [2:5][1:1] [0:M][1:3] TeamId TeamName StudentId Name TeacherId

10

11  We can use the entity relationship diagrams we design to create relational tables that can be stored in a database.  NOTE: A relational database is not just a table of information. It consists of multiple tables that reference one another.

12  Let’s mimic one together in Excel and vLookup  Download excel sheet from: http://www.u.arizona.edu/~jjenkins/mis111 _summer2011/example%20data.xlsx

13 Desktop My Documents My Network Places MIS 111CMIMy Pictures July 13.ppt Class Roster. doc

14

15  In the 1960s, a man working for IBM decided that he could improve upon hierarchical data storage.  He knew that the hierarchical model led to data redundancy and confusion.  We always have to start at the top node. That makes looking for the data I need take forever!  Sometimes I end up with the same data saved in different places! If I need to update that data, I need to do it in multiple places! 1923-2003

16  1 st normal form (Rule 1)  No repeating elements or groups of elements Take from http://www.phlonx.com/resources/nf3/

17  2 nd normal form (Rule 2)  No partial dependencies on a concatenated key Take from http://www.phlonx.com/resources/nf3/

18  3 rd normal form (Rule 3)  No dependencies on non-key attributes Take from http://www.phlonx.com/resources/nf3/

19  ER diagrams were developed a few years after Codd  If the ER diagram was developed correctly, we are automatically in 3 rd Normal Form!!!

20

21  We call this in general a “many-to-many” relationship because each entity class may have more than one instance.  Many-to-many = [M:N] [0:30] STUDENTSCOURSES enroll in [4:6]

22  We call this in general a “one-to-many” relationship because one side may only have up to one instance and the other may have many.  One-to-Many = [1:M] COURSES TEACHERS teach [0:1] [1:3]

23  We call this in general a “one-to-one” relationship because both entity classes may only have a maximum of one instance.  One-to-one = [1:1] DOCTORSPATIENTS treat [1:1]

24  Remember this? STUDENTS COURSES enroll in CourseNo CourseName StudentName StudentEmail TEACHERS teach TeacherID TeacherName TeacherEmail TeacherSalary StudentID [0:1] [1:3] [0:30] [4:6]

25  1. For every strong entity class, create a table or relation.  The identifier becomes what is called a primary key.  The other attributes become what are called non-key elements.  We can represent the STUDENTS table as such: STUDENTS (StudentID, StudentName, StudentEmail)

26  1. For every strong entity class, create a table or relation.  The identifier becomes what is called a primary key.  The other attributes become what are called non-key elements. COURSES (CourseNo, CourseName)

27  1. For every strong entity class, create a table or relation.  The identifier becomes what is called a primary key.  The other attributes become what are called non-key elements. TEACHERS (TeacherID, TeacherName, TeacherEmail, TeacherSalary)

28  TEACHERS (TeacherID, TeacherName, TeacherEmail, TeacherSalary)  STUDENTS (StudentID, StudentName, StudentEmail)  COURSES (CourseNo, CourseName)

29 StudentIDStudentNameStudentEmail 112923049Smithsmith@ua.edu 490234098Jonesjones@ua.edu CourseNoCourseName MIS111CMP_INTRNTWKD MIS373SYSTM_ANL_DSGN MIS696ARDNGS_IN_MIS TeacherIDTeacherNameTeacherEmailTeacherSalary 13445Killingerdrk@ua.eduClass_C 23489Carlkcarl@ua.eduClass_D

30  2. Locate any [1:M] relationships between strong entity classes. STUDENTS COURSES enroll in CourseNo CourseName StudentName StudentEmail TEACHERS teach TeacherID TeacherName TeacherEmailTeacherSalary StudentID [0:1] [1:3] [0:30] [4:6]

31  2. Locate any one-to-many relationships between strong entity classes. Put the primary key on the “1” side of the relationship into the table of the “M” side. TEACHERS (TeacherID, TeacherName, TeacherEmail, TeacherSalary) COURSES (CourseNo, CourseName, TeacherID)

32  “TeacherID” is now a foreign key in the COURSES table. CourseNoCourseNameTeacherID MIS111CMP_INTRNTWKD23489 MIS373SYSTM_ANL_DSGN13445 MIS696ARDNGS_IN_MISNULL TeacherIDTeacherNameTeacherEmailTeacherSalary 13445Killingerdrk@ua.eduClass_C 23489Carlkcarl@ua.eduClass_D

33  3. Locate any many-to-many relationships. Create a completely new table to represent this relationship. Use the primary keys of the participating entity classes as a new combined primary key. We now have THREE tables instead of two. COURSES (CourseNo, CourseName, TeacherID) STUDENTS (StudentID, StudentName, StudentEmail) STUDENTS_COURSES (StudentID, CourseID)

34 CourseNoCourseNameTeacherID MIS111CMP_INTRNTWKD23489 MIS373SYSTM_ANL_DSGN13445 MIS696ARDNGS_IN_MISNULL TeacherIDTeacherNameTeacherEmailTeacherSalary 13445Killingerdrk@ua.eduClass_C 23489Carlkcarl@ua.eduClass_D StudentIDStudentNameStudentEmail 112923049Smithsmith@ua.edu 490234098Jonesjones@ua.edu StudentIDCourseNo 112923049MIS111 112923049MIS373 490234098MIS111

35  STUDENTS (StudentID, StudentName, StudentEmail)  TEACHERS (TeacherID, TeacherName, TeacherEmail)  COURSES (CourseNo, CourseName, TeacherID)  STUDENTS_COURSES (StudentID, CourseNo)

36 PUPPIESSTORES CUSTOMERS buy sell StoreID StoreName StoreLoc PupAgeWhenSold PupBreed PupTemp PupID CustZip CustName CustGender CustID [1:1][1:M] [0:1] [1:M]

37  1. For every strong entity class, create a table or relation.  2. Locate any [1:M] relationships between strong entity classes. Put the primary key on the “1” side of the relationship into the table of the “M” side.  3. Locate any [M:N] relationships. Create a completely new table to represent this relationship. Use the primary keys of the participating entity classes as a new combined primary key.

38  PUPPIES (PupID, PupBreed, PupTemp, PupAgeWhenSold, StoreID, CustID)  STORES (StoreID, StoreName, StoreLoc)  CUSTOMERS (CustID, CustName, CustGender, CustZip)

39 StoreIDStoreNameStoreLoc 1Puppies ‘R’ USTucson 4Pup PlacePhoenix CustIDCustNameCustGenderCustZip 2XavierM60477 10MarthaF22303 12BillM85719 PupIDPupBreedPupTempPupAgeWhenSoldStoreIDCustID 3dalmatianactive8412 4beaglesweet1012 7laboradorsweet7412 8shih-tzuactive8410

40 INSTRUCTORSMUSICIANS teach LESSONS MusID MusName MusEmail InsID InsEmail InsName TimeDay [0:M] [1:1] MusInst

41  4. Locate any one-to-one relationships between entity classes. Take the primary key from one side of the relationship and place it in the table of the other entity class. INSTRUCTORS (InsID, InsName, InsEmail, MusID) MUSICIANS (MusID, MusName, MusEmail, MusInst) INSTRUCTORS (InsID, InsName, InsEmail) MUSICIANS (MusID, MusName, MusEmail, MusInst, InsID) OR

42  5.For weak entity classes, create a new table or relation and add its attributes. Then, add the primary key from its corresponding strong entity class. Combine all attributes to create a new primary key. LESSONS (Day, Time, MusID, InsID)

43  Convert this ERD into a set of relational tables. DOCTORSPATIENTS TREATMENTS treat [1:1] [0:M] DocID DocName PatName PatID Prscrpt Date

44  5.For weak entity classes, create a new table or relation and add its attributes. Then, add the primary key from its corresponding strong entity class. Combine all attributes to create a new primary key. DOCTORS (DocID, DocName) PATIENTS (PatID, PatName, DocID) TREATMENTS (Date, Prscrpt, PatID, DocID)

45  6. Treat aggregates just like strong entity classes. Create a table or relation.  The identifier becomes what is called a primary key.  The other attributes become what are called non-key elements.  7. Treat the aggregation as its own relationship and add foreign keys accordingly.

46 TEAMS Aggregate STUDENTS TEACHERS [2:5] [1:1] [0:M][1:3] TEAMS (TeamID, TeamCaptain, FormationDate, TeacherID) TEAMS_STUDENTS (StudentID, TeamID)

47  Quiz  Tomorrow:  I will give you / post your assignment Paper or Visio (preferred). Stencils are on the Web site  You’ll have the rest of the class time to work on it (individual assignment). This will be due beginning of class next Wednesday.  I will be able to answer “general” questions.


Download ppt "Class 9: Database Management Systems July 21 st, 2011."

Similar presentations


Ads by Google