1. Database Systems Logical Data Modelling Tutor:Ian Perry Tel:01723 35 7287 E-mail:I.P.Perry@hull.ac.ukI.P.Perry@hull.ac.uk Web:http://itsy.co.uk/units/dbs0204/http://itsy.co.uk/units/dbs0204/

2. Ian PerrySlide 2 Remember the ‘Stack’

3. Ian PerrySlide 3 What is a Logical Data Model? A ‘robust’ representation of the initial decisions made when building our Conceptual Data Model, which was composed of: –Entities –Attributes –Relationships When I say ‘robust’ I mean that this model MUST ‘perform’ well with respect to a specific style/type of software.

4. Ian PerrySlide 4 Database Theories & Software Hardware independent, the match to ‘type’ of software is our only concern here, e.g.: –hierarchyHierarchical DBMS –relationsRelational DBMS –objectsObject-based DBMS Each Database Theory addresses: –Data Structure –Data Integrity –Data Manipulation

5. Ian PerrySlide 5 Database Theory = Relational Model First proposed by Dr. E. F. Codd in June 1970. –Codd E F, (1970), A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, Vol. 13, No. 6, Pgs 377 – 387. Codd's model is now accepted as the definitive model for relational database management systems (RDBMS). Structured English Query Language ("SEQUEL") was developed by IBM Corporation, Inc., to use Codd's model. –SEQUEL later became SQL. In 1979, Relational Software, Inc. (now Oracle Corporation) introduced the first commercial implementation of SQL. –SQL is the most widely used RDBMS manipulation language.

6. Ian PerrySlide 6 Relational Modelling Language

7. Ian PerrySlide 7 Relations look very like Entities Staff (SCode, Name, Address, DoB, DoE) Contract (CCode, Site, Begin, End, Super)

8. Ian PerrySlide 8 Attributes Attribute Values are held in Data Cells: –must be atomic (i.e. simple) values only. Set of Attribute Values eligible for entry in a Data Cell: –is known as an Attribute’s Domain. The Relational Model is weak at explicitly modelling relationships: –Relations must share an Attribute Domain if a relationship is present/possible.

9. Ian PerrySlide 9 Data Access Data is retrieved by reference to name (of an Attribute) & value (held in a Data Cell) only. Most important Attribute(s) is know as the ‘Key’, of which there are two types. –Primary Key: special Attribute(s) used to control access to Tuples (i.e. rows) of data. –Foreign Key: used, as logical pointers, instead of lines to represent associations between Relations.

10. Ian PerrySlide 10 Relations are NOT Tables Tables are just data items presented in rows & columns. –Relations must obey rules (Codd’s 12 Rules). For example, we cannot have: –Duplicates: each Tuple (row) must be unique. –Row or Column dependencies there is no hidden meaning from location/sequence of Tuples (rows) and/or Attributes (columns). –etc.

11. Ian PerrySlide 11 Keys to Data Integrity Rule: –each Tuple (i.e. row) must be unique (for all time). Need a way to discriminate between Tuples: –so, each Relation must have Primary Key: There may be many Candidates for the job of Primary Key, so select on basis of: –uniqueness AND/OR minimality Keys with more than one Attribute: –are know as composite keys.

12. Ian PerrySlide 12 Other things about Attributes Attributes that are part of the Primary Key are known as Prime Attributes. Attributes not selected as part of the Primary Key are known as Secondary Keys. Secondary Key Attributes which serve as the Primary Key in another Relation are known as Foreign Keys.

13. Ian PerrySlide 13 Rules for Integrity Entity Integrity: –No Attribute that is a member of a Primary Key can assume a ‘null’ value. Else, how could we discriminate between Tuples? Referential Integrity: –Foreign Key Attributes must take values that are either ‘null’, or from same Domain as the Relation in which Attribute(s) acts as Primary Key. Else, we will lose linkages between Relations.

14. Ian PerrySlide 14 In Summary Logical Data Modelling: –is all about translating our Conceptual Data Model so that it might be implemented using software that matches a specific Database Theory. Relational Database Theory, Codd (1970): –allows us to develop mathematically rigorous abstract data models, composed of a number of distinct Relations. Tables are NOT Relations: –simply the way we choose to mentally give flesh to our Logical Data Model,

15. Ian PerrySlide 15 And Relations? –defined by a list of Attributes. –relationships via Primary/Foreign Key mechanism. Attributes? –must be distinctly named. –ordering is irrelevant. –data entries: should be atomic, of the same type, from the same domain. Tuples? –must be unique (so need a Key). –ordering is irrelevant.

16. Ian PerrySlide 16 So Staff (SCode, Name, Address, DoB, DoE) Contract (CCode, Site, Begin, End, Super)

17. Ian PerrySlide 17 And Finally! I know what you are thinking: –the Relation Definitions of a Logical Data Model looks to be exactly the same as the Entity Definitions of a Conceptual Data Model. However: –it is highly unlikely that your Logical Data Model will be exactly the same as your Conceptual Data Model. You will have made some logical errors!