1. Fundamentals/ICY: Databases 2013/14 REVISION WEEK John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK

2. EXAM (Main and Resit) CAUTION: 2012/13: DIFFERENT exam structure. CAUTION: 2011/12: DIFFERENT LECTURER and exam style.

3. Structure of Exam (9:30-11:00am, Friday 30 May) uOne and a half hours. Do three questions. uQn 1: on SQL and connection to relation operators: Weight: 32%. uICY: Three Questions on the paper. Do ALL THREE. No maths. uMSc: Those three Questions (no maths) plus one other, on maths (relations, relational algebra). l Do Qn 1 and two out of remaining three Questions.

4. Structure of Exam, contd uThe Maths question is on the connections of the maths material to uSQL (what SQL operators do, translation to and from relational algebra). udatabase concepts (nature of tables, functional dependencies, operations on tables, nature of relationships between entity types)

5. Material Needed for Exam uLecture material except when specified as optional ((incl. by double brackets)) uRequired textbook reading: l See next slide. uAll Additional Notes, except that: l The exam will NOT rely on the treatment of functional dependencies and normalization there (in the 1 st of the three parts in the Week 9 batch). l The exam will NOT rely on material on physical design (in the 3 rd of the three parts in the Week 9 batch). uAll Exercise Answer Notes (except on maths, if you’re ICY). uICY students don’t need to know about relational ALGEBRA, but they do need to know about relational OPERATORS (including the JOINs).

6. Textbook Parts uSee my module website (top page) by early next week. uOn SQL: the exam doesn’t rely on fine detail beyond what’s in the handouts (and occasional lectures). uA detailed memory of specific, data-full examples from the textook is not expected.

7. MODULE REVIEW

8. What We Mainly Studied uThe nature of relational databases, the central modern type of database. Entity types represented as tables, holding relations. uSome basic mathematical concepts underpinning relational databases, and useful also in many other branches of CS. uKey aspects of how to develop the conceptual/logical design of relational databases. uIn particular, how to achieve certain types of good structuring, to help achieve certain types of correctness and efficiency. uHow to create and query databases using a particular database language, PostgreSQL (a version of SQL: very widely used in various forms).

9. Initial Considerations uWhat a database is, and how it relates to other types of data structure/repository in CS. uData integrity, data redundancy, data anomalies. uAssociative links between parts of a database, as opposed to pointing. uWays data is stored/linked in physical human media such as diaries, address books and timetables. uVarious complications in tables in human documents. uRestricted type of table used in relational DBs.

10. Entities and Relationships uAny relational DB as consisting of entity types and relationships between them: Entity Relationship Model (ERM) in general. uSpecific ERMs for specific applications, and distinction from Entity Relationship Diagrams (ERDs). uEntity Types as represented by tables. uThe question of what types of thing should correspond to “entity types,” and hence tables, depends on the application and your design judgment.

11. Attribute Determination and Keys uOne or more attributes determining another attribute. Can also be described as that attribute being functionally dependent on the former attributes. uVarious notions of key, especially superkeys, candidate keys and primary keys … uAnd foreign keys as the (main) implementation of relationships between entity types.

12. Strength and Weakness uStrong and weak relationships. (Also called identifying and non-identifying relationships respectively.) uWeak entity types, as defined according to the strength of their relationships to other entity types and existence- dependence with respect to those types. uDepiction of strength or weakness in different styles of ERD.

13. Connectivity, Cardinality & Participation uConnectivity: uniqueness or multiplicity of entities at either end of a relationship. uCardinality: precise numerical info about how many entities allowed or required at either end of a relationship. uParticipation: optionality or mandatoriness of a relationship, in either direction. uOverlap between these notions. uNotation in ERDs.

14. Table Representation of Relationships of Different Connectivities uBasic case is 1:M non-recursive. (Recursive is when two or more entity types in a relationship are the same.) u1:M recursive—can often be handled within a single table. uM:N, M:N:P, etc. standardly handled by breaking down into two, three, etc. 1:M relationships going to a new entity type: a “bridging” or “linking” type. uSymmetric relationships (e.g. marriage). Special problems of redundancy arise. Can be avoided by a special implementation involving two extra tables, together serving a bridging function. l Symmetric relationships are recursive and are either 1:1 or M:N.

15. 1-1 Relationships uIf you find yourself using a 1-1 relationship, especially when unchanging, mandatory in both directions, and non-recursive: ask yourself whether the two entity types could be combined into one without causing difficulty. l E.g., if there were an unchanging 1-1 relationship, mandatory both ways round, between employees and phone stations, you could probably combine into one entity type without difficulty, increasing efficiency of some operations. l But if the relationship changes frequently, easier to have 2 types/tables. l And if the relationship is optional in at least one direction, using one type leads to more wasted space.

16. 1-1 Relationships, contd uSome good, standard uses of 1-1 relationships: l [As just mentioned] Cases where there is a significant amount of change or optionality. l Subtype/supertype relationships: naturally 1-1; useful to keep the types separate. l Symmetric 1-1 relationships such as marriage: only one entity type anyway.

17. Other Representation Issues uMultivalued attributes. OK in themselves in early stages of design, but should eventually be broken down into single-valued attributes in some way. A main divergence in ways of doing this is based on whether the different values are for stably identifiable sub-attributes. uGeneralization hierarchies. Exhaustiveness, disjointness.

18. Normalization uWhat normalization is and what role it plays in the database design process. uThe normal forms 1NF, 2NF, 3NF, BCNF. l 4NF (two versions) was left as optional material. uHow tables can be transformed from lower normal forms to higher normal forms. uThat normalization and ER modeling are used concurrently to produce a good database design, helping to eliminate data redundancies & anomalies. uThat some situations benefit from non-normalization to gain efficiency for some operations.

19. Creating ER Models/Diagrams uDesigning an ER model for a database is an iterative process, because, e.g.: l As you proceed, you think of new ways of conceiving what’s going on (much as in ordinary programming) l Multivalued attributes need to be re-represented l M:N relationships can be included as such at an early stage, but generally need to be replaced by bridging entity types at some point l 1:1 relationships raise a red flag, though may be justified. l Special supertype/subtype notation needs eventually to be converted into more standard diagram notation, to correspond to the actual tables used. l Conversion to Normal Form (NB: different parts of the DB may have different needs)

20. SQL uMainly, the module only covers basic SQL mechanisms for querying, creating and updating tables. uSee manual and textbook for much more if you want!

21. MATHEMATICAL VIEW

22. Tuples, Relations and Tables uA relation on some sets A, B, C, … is simply a set of tuples all of the same length, where in each tuple the first element is from A, the second from B, etc. uA relation is therefore a subset of the Cartesian product of those sets. uA row is a tuple. Hence a table at any given moment induces a relation over the value domains of the table (augmented as appropriate with the value NULL). uThe table consists of not just the induced relation but also the attributes themselves, their domains, specification of primary and foreign keys, etc.

23. Functionality of Relations uFunctional relation from A, B, …C to some sets:  for each choice of values from A, B, …, the relation contains at most one tuple starting with those values. l Also called a partial function. uFunctional dependence relationship, i.e determination relationship X, Y, …, Z  U within a table:  induces a functional relation from the value domains for X, Y, …, Z to the value domain for the determined attribute U.

24. Some Categories of Relation uOne-to-one uOne-to-many and many-to-one uMany-to-many

25. Relations from Entity Relationships uThe connection between relationships in ERMs and mathematical relations. l E.g., the EMPLOYED-BY relationship from the People entity type to the Organizations entity type says that the database (at any moment) stores a relation from the People entity set to the Organizations entity set. uThe connection between connectivity of a relationship between entity types and the issue of whether the corresponding relation is one-to-one, functional, etc. uThe connection between mandatoriness of a relationship from entity set E to entity set F and notion of relation totality. (A mandatory relation is total on the set of current E things.)

26. Some Operations on Sets in General uUnion, intersection, difference, symmetric difference and Cartesian product of two sets X and Y (of any sort). uWhen X and Y are relations: Note the set of all possible concatenations of a tuple within X and a tuple within Y.  I have called this the flattened Cartesian product of X and Y, notated as X  Y as opposed to X  Y. Often called the relational product in the DB world. (Shouldn’t be, but often is, called the Cartesian product.)

27. Relational DB Operators & Relational Algebra uDefines theoretical way of manipulating tables using “relational DB operators” that mainly manipulate the relations in the tables. SELECT PROJECT JOIN (various sorts) INTERSECT uUse of relational DB operators on existing tables produces new tables. Strong connection to SQL commands/operators. uRelational algebra puts relational DB operators into a mathematical notation that is more convenient than, e.g., SQL operators. UNION DIFFERENCE PRODUCT (DIVIDE)

28. QUESTIONS?