Fundamentals/ICY: Databases 2010/11 WEEK 3 John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK

Answer Notes! uWeek 1 exercises: on the web set, via Exercises page uWeek 2 exercises: will be available after tomorrow

Lab/SQL Work Starts this Thursday! uThis week you start on getting familiar with the PostgreSQL system and doing some SQL exercises (two batches). uSee Week-3 Handouts and Exercise Sets on my module site. uThursday lab session: l upper ground floor lab, Linux machines l try find demonstrators in their offices if not in lab

Reminder of Week 2

Restrictions on Database Tables: Overall Structure uRegular overall shape: rows all same length, similarly columns. uNo division into different regions (with a certain exception). uNo labels for rows, as opposed to columns. Mostly no significance to the order or number of rows (but the number can change). uNo additional comments, footnotes, etc.

Restrictions on Database Tables: Nature of Entries uAll cells in any one column are given the same intuitive interpretation. uEach cell’s item restricted to a pre-specified, fairly simple format, and all cells in any given column restricted to same format. uNo exceptional entries … with one exception!: empty entries uOne data item per cell (but it can be a variable-length character string, containing anything). uUncertainty and vagueness markers not supported.

Extra, Crucial Restriction (on the main tables) uNo row can be repeated in a table. (I.e., no two rows can contain exactly the same values.) uThis is equivalent to saying: Rows are uniquely determined (picked out) by the values in some set of columns (possibly the whole set, but could be fewer). That is, if you imagine some values for those columns, there is at most one row that has exactly those values in those columns.

New for Week 3

LAST N.FIRST NMIADDRESSHome PhMobileB yearB day PorkypastaBabloop107 Worm Drive, Hedgebarton, Birmngham, B15 9ZZ Jan 11 O’CrackpothamCoriolanusZThe Wellyboots, Boring-under- Mosswood, Berks, HP11 1XX DelfinoJohnny-----Next to the Tesco’s in Upper Street ClintonHilaryRThe Old Black House, Aplanalp St., Las Cruces, NM , USA-----Sep 16

Coordination between Tables NAMEPHONEEMPLOYERAGE Chopples University of Birmingham 37 Blurp Monmouth School 21 Rumpel University of Birmingham 88 EMPLOYERADDRESSNUM. EMPLSSECTOR BTBT House, London, … 1,234,5678Private TCOM Monmouth School Hereford Rd, Monmouth, … 245Private 2E University of Birmingham Edgbaston Park Rd, …. 4023Public HE PHONETYPESTATUS officeOK homeFAULT homeOK mobileUNPAID There should really be a FIRST NAME as well, in practice

Remember: “Associative Linking” This is how the tables are linked.

But: What are the disadvantages of using character strings like “University of Birmingham” as linking values?

The Disadvantages uIn entering values, have to ensure exactly the same string of characters on each occasion l avoid typos on data entry l avoid variants: “The University of Birmingham” uDifficult to guarantee that two different entities won’t have the same name. uInefficiency of comparing such complex values. Reduce such problems by: uUsing artificial linking values that are simpler in form and easier to make distinct …..

Table Coordination: Revised NAMEPHONEEMPL. IDAGE Chopples E Blurp E Rumpel E EMPL. IDEMPL. NAMEADDRESSNUM. EMPLSSECTOR E48693BTBT House, London, … 1,234,5678Private TCOM E85704Monmouth School Hereford Rd, Monmouth, … 245Private 2E E22561University of Birmingham Edgbaston Park Rd, …. 3023Public HE PHONETYPESTATUS officeOK homeFAULT homeOK mobileUNPAID

Redundancy between Tables NAMEPHONESTATUSEMPLOYERAGE Chopples OK University of Birmingham 37 Blurp FAULT Monmouth School 21 Rumpel UNPAID University of Birmingham 88 PHONETYPESTATUS officeOK homeFAULT homeOK mobileUNPAID What are the advantages and disadvantages of the sharing of the STATUS attribute?

Tables and Things u The example tables involve various types of thing: l People l People’s names l Addresses l Phone numbers l Phone number types l Dates l Ages l Status indicators l etc.

uand also various types of connection between things, e.g.: l A person having an address l A person being employed by an organization l An organization having some employees l A person having a birth date l A phone number being of a type l A phone number having a status l etc.

ORGANIZATIONS (each with …) PHONE STATIONS (each with number, type & status) a person may be employed by one(?) organization a person may have one(?) phone station PEOPLE (each with name, address, etc.) PHONE EMPLOYER

You Judge Only Some Types of Thing to Merit Tables uIn the example above we have decreed that only the people, employing organizations, and phone stations CATEGORIES correspond to WHOLE TABLES. l In one table, each row represents a person. l In another table, each row represents an employing organization. l In yet another table, each row represents a phone station. uWe have decreed that the other types of things, such as people’s names, addresses, phone numbers, phone-number types, etc. correspond only to COLUMNS of tables, not whole tables, and each individual thing is just represented as a value in a cell.

Meriting Tables, contd. uThe question of what types of thing should correspond to tables depends on the application and your design judgment. uIt all depends on things like: l what range of information is needed about something l how separate the pieces of info about a given thing are l what operations are needed l how often they’re needed. u For example:

Typical Approach to Phone Numbers NAMEPHONEEMPLOYERAGE Chopples E Blurp E Rumpel E (There should really be a FIRST NAME as well)

But the following is possible … NAMEPHONE IDEMPLOYERAGE ChopplesABC123E BlurpABC137E RumpelDEF678E PHONE IDAREA CODEBODY ABC ABC DEF DEF There should really be a FIRST NAME as well

Some Operations on Individual Tables uCreating a new empty table of a particular “shape” (mainly, particular column names and value-types for the columns) uChanging the “shape” of an existing table (e.g., adding/deleting a column, or changing the type of a column) uAdding a row or rows to a table uDeleting a row or rows (question: how identified?) uUpdating values in an individual cell (column specified by name; but how identify the row?)

More Operations on Individual Tables uRetrieving values from an individual cell; doing calculations on them uRetrieving the values in the cells in some or all columns for some or all rows uCalculating statistics concerning values in particular columns across all rows, a subset of rows, or several subsets of rows (count, max, min, average, standard deviation, …) uOrdering rows in different ways in displays of a table.

Operations on Coordinated Tables uNeed to be able to combine data from related tables in a variety of ways. E.g.: l Join tables together in various ways l Select things from one table on the basis of information in others uNeed to ensure consistency between related tables. E.g.: l Deletion of something in one table may require deletions from or other modifications to other tables.

ENTITIES, RELATIONSHIPS & ATTRIBUTES (Introduction)

Entities uBasically, entities are just things of the “important types” that we judged above to merit tables. So we had entity types such as: l People l Employing Organizations l Phone Stations (as opposed to just phone numbers as such) uSo what the entity types are in a given working environment are partly a matter of judgment, as explained earlier. But we’ll see that in designing a DB we may need to introduce new, not immediately obvious, entity types. u“Entities” are, or should be, the things of a type: e.g., individual people. An entity is represented by a row in the appropriate table.

Entity Terminology uUnfortunately: “entity” is often used to mean entity type. “entity set” is often used for entity type. “entity occurrence” is often used to mean individual entity.

Relationships uThese are the relationships between entity types, such as l A person being employed by an organization l A person having a phone station uHave to think about both directions of a relationship: e.g., both employed-by and employs. uCAUTION: Tables are also called “relations” [hence “relational” DB] (much more on this later). This is to do with the internals of tables/entities rather than with “relationships” between entities.

Relationship Connectivity uRelationships are importantly categorized as to uniqueness or multiplicity of entities at either end – “connectivity.” Has big effect on DB design. l 1:1 (“one to one”): e.g., the people/phone-stations relationship, if each person has at most one phone station and each phone station is assigned to at most one person. l M:N (“many to many”): e.g., the employs relationship, assuming a person may have more than one employing organization (or none) and an organization may have more than one employee (or none). (Don’t take “many” seriously – just means possibly more than one.) l 1:M (“one to many”): e.g., the employs relationship, if an organization may have more than one employee (or none) but a person has at most one employing-org.

Relationship Cardinality uRelationships can be further specified as to “how many entities allowed or required at either end” – cardinality. Also has significant effect on DB design. uIn a relationship from entity type A to entity type B, a minimum and a maximum can be specified for the number of B entities for each A entity. uA maximum greater than 1 can only be specified if the relationship from A to B is 1:M or M:N. (So the notions of connectivity and cardinality are not properly separated). l E.g., could be specified that a person can only be employed by up to five organizations. uMost normally, the important choice for the minimum is between none and one. E.g., the minimum for employed-by could be none, but the minimum for employs could be one. But the minimum number of wheels for a car could be specified to be three. uIf the minimum is none, then B is optional for A. Otherwise, it is mandatory for A.

Attributes uAttributes of entities of a given type are the names of the different pieces of information that need to be stored for entities of that type. So they’re just the column names for the table for the entity type. l E.g., entities of the type “people” could have the following attributes: person ID number, last name, first name, phone number, age. uNote: Attributes include artificial ones like the employer identity numbers (EMPL. NUM.) that we introduced in an example above. These may have no significance outside the DB itself. uRelationships are represented by associative linking by means of shared attributes. (For now, will always assume that the same attribute name is used in each of the tables involved.)

Attribute Determination uREMEMBER: Rows in a table are uniquely determined (picked out) by the values in some set of columns, i.e. the values of some collection of attributes. That is, given some values for those attributes, there is at most one entity that has those values for those attributes. uHence, that collection of attributes determines all the other attributes. uThat is, given some values for the determining attributes, there’s at most one value for each of the other attributes.

Attribute Determination, contd. (corrected after lecture) uMore generally, a collection of one or more attributes determines another attribute A if only one value for A is possible given the values for the former attributes. E.g., the collection DAY-NUMBER, MONTH and YEAR specifying birth-date in a table about people (not days as stated in class) could determine DAY-NAME, even though it doesn’t determine other attributes such as NATIONALITY: several people could have the same birth-date but be of different nationalities. uWe alternatively say that DAY-NAME is functionally dependent on DAY-NUMBER, MONTH and YEAR.

Attribute Determination, contd. (modified after lecture) uThe determining collection of attributes is called the determinant in the determination. uWrite determination as: DAY-NUMBER, MONTH, YEAR  DAY-NAME uDetermination does not mean that you have at hand an algorithm for working out a dependent attribute from the determinant, although you may do. E.g. Consider a “father” attribute.