Tutorial 1 Entity Relationship Modelling

Entities and what they mean One-to-many Header-Items Invoice/ Invoice Items Customer/ Customer- Branch Bidirectional view Supplier/ Parts Books/ Characters

So what does that mean ? (1) CUSTOMER(CustID, CustName, CustAddress, Credit_Limit, Curr_Bal) CUSTBR(CustID, BranID, BranName, BranAddress, Credit_Limit, Curr_Bal) On INSERTing CUSTBR record check that CUSTBR.CUSTID is in some CUSTOMER.CUSTID

So what does that mean ? (2) CustIDCustNameCustAddrCredit_LimCurr_Bal Dunn0001Dunnes Stores Main Street, Dublin £1000£15.45 CustIDBranIDBranNameBranAddrCredit_LimCurr_Bal Dunn0001RATH0001RathminesDublin 6£200£0.40 Dunn0001JERV0001Jervis St.Dublin 2£300£6.05 Dunn0001DAWS0001Dawson St. Dublin 2£300£6.00 Dunn0001WICK0001Wicklow £200£3.00

Developing a Data Model Entity-Relationship modelling How to get an ERD

8 Entity Relationship Modelling Top down approach –who or what do we need to store data about? Steps involved: –identify the entities about which the system needs to store data –for each entity, list its attributes –for each entity, identify the attribute(s) that will uniquely identify it –identify the relationships between the entities –define the type and optionality of each relationship –update the data dictionary with definitions of the entities –check each attribute against the data dictionary and data flow diagrams

Data and MetaData Data is the value that you expect to be held in an attribute. –e.g. My name is Patricia O’Byrne and I lecture Software Engineering Meta-data is the description of the data: –Lecturer Name: Patricia O’Byrne –Subject: Software Engineering –The meta-data is consistent for all subjects Attributes are meta-data. If you can’t put a value on an attribute, it is data, not meta-data!

Tables and Documents Most systems, especially manual ones, are based around forms. A form is not an entity - i.e. not relational. We expect forms to be ‘unnormalised’ – i.e. unsuitable for immediate use as an entity. If any of your entities are forms, they need more attention. You need to normalise forms to uncover the Entity Relationship Diagram.

Resolving ‘many to many’ relationships Often with many to many relationships there is information associated with the relationship that cannot be attached sensibly to either entity. e.g. STUDENT and SUBJECT which entity should hold the “mark”? –attaching data to one or other entity results in repeating data

Resolution Many to many relationships are always resolved into two one to many entities with the introduction of a new entity called a link (or weak ) entity –e.g. RESULTS entity is the link between STUDENT and SUBJECT entities The primary key of a link entity is always the combination of the primary keys of the entities in the relationship it is resolving.

Data Dictionary conventions for data models –entities written in capitals where there is more than one word, words are joined with underscore ‘_’ character –data items that are primary keys are underlined –foreign keys are marked with asterisk *

Defining entities and attributes Pick out nouns from the script. –External entities –Process names –Internal entities –Attributes –Values Eliminate all except the entities and attributes. Try to ensure that you are not treating an external entity or business actor as a stored entity.

Describing Entities An entity is denoted by all capital letters, followed in parentheses by a list of its attributes: STUDENT(StudentNumber, StudentName, CourseCode, CourseYear, HomeAddress, PhoneNumber) Entities should not repeat, each one should be different.

An entity or not an entity? An entity is an entity if –Information needs to be kept on it –The information that needs to be held on it Is not part of another entity Probably consists of more than one data item E.g. –A STUDENT entity is described by the following: –StudentNumber, Name, CourseCode, CourseYear, HomeAddress, PhoneNumber.

Attributes An attribute if –It describes the entity, but has little value outside the context of the entity. –An attribute has a datatype and a length. –E.g. StudentName can have a value of “Mary O’Reilly”. It has a datatype of string and a maximum length of 30.

Candidate key A candidate key is an attribute, or group of attributes that can uniquely define an individual occurrence of an entity. Let’s assume we have an entity of customers. Consider the following conversation: –“Do you know John Brown?” –“Yes, I do. He lives in Hill St.” –“No, I mean the other John Brown, he lives over in Valley St.” To distinguish between the two people, both the name and address of the person is required. Therefore, the name is NOT a candidate key. The name and address MAY be a candidate key, unless… –“Do you mean John Brown Senior, or John Brown Junior?”

Candidate key contd. Candidate keys may be simple: –StudentNumber is a candidate key for STUDENT. Or compound: –CustomerName + CustomerAddress + CustomerDateOfBirth is a candidate key for the CUSTOMER entity. If the candidate key is not suitable, a key may be imposed: –Let’s give our CUSTOMER a CustomerNumber. That would be much shorter to store and to retrieve.

Foreign Key An attribute is a foreign key if –It describes another entity in a single or compound data item –Its purpose is to point to another entity. E.g. the CourseCode attribute in the STUDENT entity. –Another entity called COURSE must exist, where CourseCode is the primary key.

Maybe not in the schema at all? An EXTERNAL entity if –It provides information to the system / takes information from the system, but no information about it is stored. This has no place in your ERD. –An example of this would be someone who browses on the Internet without registering or buying. While they are essential to the running of the process, no data is kept on them.