Data modelling uses two main techniques Entity relationship (E-R) modelling: a top- down approach Normalisation: a bottom-up approach

E-R modelling: looks for the data objects in the system is a useful first attempt to organize the data results in a data model which may be incomplete is based on common sense rather than mathematical rigour

Normalization processes the data items collected during fact-finding follows well-defined rules structures the data items into a related set of entities

Named relationship

The degree of a relationship Customer to Order is one to many any one customer places many (one or more) orders any one order is placed by just one customer. A relationship indicated by a line between entities The degree of the relationship indicated by a crow’s foot on the many end of the line.

Relationships between entities can be: One to one One to many Many to many The terms multiplicity and cardinality are sometimes used

Optional and mandatory relationships Optional if an occurrence of one entity to can exist without being associated with an occurrence of the other entity. The relationship between the entity Mother and the entity Son: mandatory for Son (must have (had) a mother) optional for Mother (all her children may be daughters) optional relationships shown by dashed lines mandatory relationships by solid lines

Optional relationship for Mother, mandatory relationship for Son

Mandatory relationship for both Student and Course

Summary of notation for data modelling

Enterprise rules rules that govern the data in the system i.e.what data the system requires and how the data items relate to each

Redundant data Data is deemed to be redundant in the following situations: The data is never used by the system. The same data items (e.g. customerName, customerAddress) are stored in more than one place in the system. Data in one place can be derived from data held in another place in the system (e.g. the total order price can be derived from the individual item prices and ordered quantities).

The library system A library keeps records of loans, books and members. It stores members’ names, addresses, status (junior or senior), loan limit (number of books a member may borrow) and date of birth; members are given individual member numbers when they join the library. The library also stores information about its books: title, authors, publishers, publication date, ISBN and purchase price. As some books are very popular, the library often buys several copies of the same book. All loans are for three weeks. The library needs to be able to record, edit and delete member details; record, edit and delete book details; record loans and returns, and reserve books. Overdue notices are to be sent when books are overdue. It also wants its library system to automatically update member status. The system must also record the current price of a book.

Enterprise rules: library data Individual copies of books are identified by library ID number; loans: the library needs to be able to identify which copy of the book has been borrowed - use library ID number; The book itself, i.e. a specific title/author combination, is identified by its ISBN;

Enterprise rules Members are identified by member number; Member status determines how many books a member may borrow – the ‘loan limit’. To keep the example simple, we are ignoring issues relating to fines for overdue books. Do this example in the class