1. The Relational Model Lecture #2 Monday 21 st October 2001

2. Communications Web page: http://macha.wit.ie/staff/eleray/WIT/Diploma All the slides and labs will be available on this intranet site

3. Textbook(s) Database Systems: A practical Approach to Design, implementation and Management Second Edition by Thomas Connolly and Carolyn Begg Edition Addison-Wesley

4. Designing a Database Lecture Outline The fundamental process What are we trying to do? Why do we need a model? Why the ER model? A concise approach to ER modelling What other models or methodologies might we use?

5. The Fundamental Process Figure out what the data is. Figure out what the users want to do with the data. Determine both the logical schema and the physical layout. bottom-up vs. top-down normalisation vs. ER modeling

6. DB Design Process Objectives Derive a logical description of the data. Understand the various ways in which the data is used. Identify the important or central data. Evaluate the relationships between data and how to decompose a design. Organise the data to facilitate the uses. Be reasonably efficient and allow for more efficiency of implementation.

7. DB Design Process Dangers The users don't really understand the data. Each user will give you a myopic view, hence it’s your job to reconcile the different views. Each individual description of the data must be complete and accurate. Existant data might be messed up: Fields have changed meaning Fields are used for multiple purposes There were data entry errors that were never corrected No one really knows what all the fields mean

8. Need for a Model Complexity of the data. The data and design will evolve over time: You want a history of this evolution. You want to be able to make changes without constantly dumping and loading your data. A graphic model enables easy understanding of the data and its relations. Good mental structuring will lead to good physical structure.

9. The ER Model Maps nicely into a relational data model. ENTITY, RELATIONSHIP, ATTRIBUTES  TABLES, COLUMNS Provides a set of terminology and a graphical display of the data. Square Box, Ellipse, Diamond, Line. Fairly simple to understand.

10. Conceptual Modeling address namelid Lecturer Mentors Takes Teaches Course Student name address quarter name studnb cid

11. Understanding the Terminology Entity Type & Entity Attributes & Attribute Domain and Keys Relationship Type & Relationship

12. Entity Type & Entity Entity Type: An object or concept that is identified by the enterprise as having an independent existence Entity: An instance of an entity type that is uniquely identifiable Representation An entity is represented by a rectangle Entity

13. Attributes Attribute: A property of an entity or a relationship type Attribute Domain A set of values that may be assigned to an attribute Representation An attirbute is represented by an ellipse {*} Attibute

14. Attribute Classification Simple Attribute –An attribute composed of a single component with an independent existence Composite Attribute –An attribute composed of multiple compnents, each with an independent existence Derive Attribute –An attribute that represents a value that is derivable from the values of a related attribute or set of attributes, not necessarily in the same entity. Derived attribute Compose d attribute Part 1 Part 2 Simple attribute

15. Key Attributes Candidate Key An attribute or set of attribute that uniquely identifies individual occurences of an entity type Primary Key The candidate key selected to be the primary key Composite Key A candidate key that consists of two or more attributes Representation The name of each primary key attribute is underlined Key

16. Relationship Type & Relationship Relationship Type: A meaningful association among entity types Relationship: An association of entities where the association includes one entity from each participating entity types Representation An relationship is represented by a diamond Relationship

17. Relationship Classification Relationship Degree The number of participating entities in a relationship e.g.: Binary, ternary, quaternary, etc… Recursive Relationship A relationship were the same entity participates more than once in different roles e.g.: Staff(doctor) supervises Staff(PhD wanna-be)

18. Attributes on Relationship All attributes that have been described can ben assigned to relationships. However be careful that the presence of one or more attibutes assigned to a relationship may indicate that the relationship conceals an unidentified entity. E.g.: Staff Student meets Meeting date comments

19. Structural Constraints Constraints reflect the restrictions on the relationships as they are perceived in the real world. We distinguish two different type of constraints: cardinality and participation constraints. Cardinality Ratio Describes the number of possible relationships for each particianting entity. The most common degree of relationships is binary and the cardinality ratio for binary relationships are one-to- one (1:1), one-to-many (1:M) and many-to-many (N;M)

20. Cardinality Constraints: (1:1) One-to-one relationships e.g.: A lecturer can be manage one-and-only-one course as well as a course can be managed by one- and-only-one lecturer at a time. 123123 abcdabcd 11 OR

21. Cardinality Constraints: (1:M) One-to-many relationships e.g.: A student follows one course. But a course is taken by many students. 123123 abcdabcd M1 OR

22. Cardinality Constraints: (N:M) Many-to-many relationships e.g.: A lecturer can teach many subjects. A subject can be tought by many lecturers. 123123 abcdabcd MN OR

23. Participation Constraints Participation constraints Determines whether the existence of an entity depends upon it being related to another entity through the relationship Total participation constraints e.g.: A class can not exist without a student Partial participation constraint e.g.:A fullt-ime lecturer needs at least 9 hour to teach but cannot teach more than 24 hours. {N:M}  {9,24}

24. Other Modeling Techniques Object Definition Language [ODL] ODL helps in defining objects and interfaces. Properties of objects can be relationships. UML UML is widely used for system modeling and its starting to be widely accepted for data models {using class diagrams}. Merise used in France. {quite similar to ER}

25. Conclusions Make up your own summary of the ER notations Practice with simple examples Try to do the homework #1 Homework #1 will be available on macha.wit.ie on Wednesday!