COMP 1630 Relational Database Design and SQL Questions for Group Discussion Week 02 Discussion Rules 1.

Pick a moderator for this week. This person must moderate, organize and summarize this week's discussion. This person must submit a final document to your respective groups dropbox folder in D2L ( http://learn.bcit.ca) before the deadline that contains all team members' contributions. - Moderators should be rotated in a round robin fashion. - Post who the moderator for the week is. 2. As a group, divide up the group questions and set a deadline for these questions internally within your group. Post the division of questions in this thread. Note that some questions must be answered by all members. All team members must participate in completing all the questions within your deadline to allow the moderator time to prepare the final document. 3. All intermediate discussions must be posted in the group thread.

5. Always put all the members names in the final document. Clearly indicate who the moderator is. Provide the Week #, date, and clearly write the questions being answered. 6. All members in the group will receive the same marks - unless one or few team members clearly have not contributed, or they have been reported by the rest of the team members to the instructor as not participating, in which case the team member(s) will receive 0. 7. Without the final document from the moderator, the maximum mark will be 5/10. 8. As much as possible, try to explain in your own words. DO NOT COPY verbatim from other sources, and ALWAYS cite your references and sources. Late submissions not accepted

Questions to Ponder everyone in the group must answer these questions

1. Pick one topic we discussed in week 02, and summarize in 1-2 paragraphs. Do not pick a topic that your team member has already picked. RELATIONSHIP A relationship describes an association among entities. Data Models use three types relationships: One to-one (1:1 or 1..1); many-to-many (M:N or *..*);one- to-many (1:M OR 1..*). Each relationship is in both direction; that is, relationship are bidirectional. The 1:M relationship is the relational modeling ideal. Therefore, this relationship type should be the norm in any relationship database design. For example, in my company, each student can only take one course, which means each student will only have one instructor, but each instructor can teach multiple courses which means each instructor can have multiple students. The relationship between students and instructors are 1 to M. The 1:1 relationship should be rare in any relationship database design. For example, in my company, each site has one site manger and each site manager only manage one site. Site and manager relationship is 1:1. A M:N relationship is not supported directly in the relationship environment, however relationships can be implemented by creating a new entity in 1:M relationships with the original entities. For example, in my company, the relationship between the clients and services are M:N. The feature are : the clients can have many services and each service is available to multiple clients. Cited from Database Systems: Design, Implementation, and Management, 10 th Ed 2. In your own words, why is it important to create and use data models? Feel free to provide examples to support your explanation. One of most frustrated problems is data programmers, designers and end users see the data differently. Different views of the same data can lead to a failing to meet end-users needs and data efficiency requirement. Data Modeling helps end users, programmers and data designers understand their own needs, have the same view of the data, and help them communicate at the same page. For example, while we are using central database at my company, an essential issues is WHO SEES WHAT? Different department has its own rules, policies and procedures even though involved the same entity For instance, in family program, children s definition is from 20 months up to 16 years, but in childminding program, children s definition is from 18 months to 5 years. Another simple example without a good data models will caused the conflict that while the designer didnt set up the certain format of date, then you will constantly see the data like : 12/5/13 that you are not sure if it is May 12, 2013 or May 13, 2012 or December 5, 2013 due to different end users type habit. Therefor creating and using a data model is an essential and efficient communication tool among data programmers, designers and end users.

3. How do you translate business rules into data model components? Business rule set the stage for the proper identification of entities, attributes, relationships, and constraints. As a general rule, a noun in a business rule will translate into an entity in the models, and a verb (active or passive) that associates the nouns will translate into a relationship among the entities. For example, the business rule a customer may generate many invoices contains two nouns (customer and invoices) and a verb (generate) that associates the nouns. To properly identify the type of relationship, you should consider that relationships are bidirectional; that, they go both ways. As a general rule, to properly identify the relationship type, you should ask two questions: How many instances of B are related to one instances of A How many instances of A related to one instances of B? Cited from Database Systems: Design, Implementation, and Management, 10 th Ed

8. What will an EQUIJOIN between STUDENT and PROFESSOR produce?

T1 : STUDENT INNER JOIN PROFESSOR ON STUDENT.PROF_CODE=PROFESSOR.PROF_CODE STU_CODE 128569 512272 531235 553427 PROF_CODE 2 4 2 1 PROF_CODE 2 4 2 1 DEPT_CODE 6 4 6 2

13. What will an INTERSECT between BOOTH and MACHINE produce?

BOOTH INTERSECT MACHINE BOOTH_PRODUCT Energy Drink BOOTH_PRICE 2

18. What is the difference between a physical and an internal model? Physical and internal model are used in different stages of development. Internal model is level of business requirement and representation of the database as seen by the DBMS maps the conceptual model to the DBMS, but physical model represents the actual design of database and operates at lowest level of abstraction - describes the way data are saved on storage media such as disks or tapes. It goes into a schema level design that transformed into relationship database. Internal schema depicts a specific representation of an internal model. Physical Model requires the definition of physical storage and data access methods. Internal Model depends on specific database software change in DBMS software requires internal model be changed. Physical Model is relational model aimed at logical level doesn't not require physical-level details. Internal Model is logical independence : change internal model without affection conceptual model. Physical Model is physical independence changes in physical model do not affect internal model. - Cited from lecture slides.