Logical Data Modeling Review Lecture for University of Agder, Grimstad DAT202 Databaser (5.5.11) Judith Molka-Danielsen

Overview Real world problem: Represent order taking activity in logical relational database that will allow quick and accurate retrieval of data. Relational models are dimensional – all pieces are not in one physical file. We need to convert a physical database to a logical relational data model, using relations between customers and orders of products. To convert the physical world to a logical data model we must: 1.Identify candidate keys 2.Select primary keys (PK) 3.Apply normalization Goal of the prior steps is to produce an Entity Relationship Diagram (ERD).

Data elements Order Clump- related data file – each field is a data element – OrderNr – OrderDate – CustomerNr – CustomerName – CustomerAddress – ItemNr – ItemName – ItemQuantity – ItemPrice – ItemAmount CustNrCustNameQuantityPriceItemAmount 1 2 …many Line items are occurrences of every item associated with an order.

Keys Candidate keys – We look for attributes that uniquely define the data element. For example, a personal number can be used to uniquely define an employee. There can be more than one candidate key. The employee can be found by an EmployeeID also. But the winner should be the one that is used the most to find the employee, and this becomes the Primary Key (PK). In our example we pick OrderNr as the PK. No other order has the same order number. Other keys can be used to find the record, but are not included in the logical data model. (secondary or alternative keys) Foreign key (FK) – a common data element between two groups of associated items. This can be between two or more primary keys. EmployeeIDPrimary Key (PK) PersonalNrSecondary or alternative key

Some ERD defintions Entity – object, thing. A file in logical modeling is called an entity. Entity type – a class of entity, e.g. customer. Entity instance (occurrence) – a specific entity, ”customer number 2000” Attribute – properties of an object. Elements become attributes. Attributes specify properties of an entity, e.g. CustName Relationship – association among entities. Describes the connection between two entities. Relationships between entities of the same type have the same attributes. Degree – number of occurrences of each entity (1:m), (1:1), or (m:m). Dependency – means changes in an element (OrderNr) will change what you are looking at in the data. Entities and relationships in the ER can map to relationships in the relations database (RDB). Not all relationships in the ER map to relations in the RDB.

Normalization Normalization has two purposes: – Removal of data redundancy – Data integrity is maintained Integrity – ”Completeness: unity. Soundness. Complete and not corrupted. ” Normalizaton protects integrity of data, because it provides referential integrity between data fields. If you violate Normalization, the integrity of the data is at risk.

Normalization – The rules of one One type of items = one entity (table) One Item = one tuple (row) One descriptive fact = one attribute (column) Every attribute must describe the entity

Normalization 1st Normal Form (1.NF) – There must be no repeating elements (no repeating groups). 2nd Normal Form (2.NF) – There can be no partial dependencies on part of the PK. 3rd Normal Form (3.NF) – There can be no non-key attributes dependent on another non-key attribute (that is we cannot have 2 elements dependent on each other). This is called ”decomposition” – breaking the data down into dimensions. How do we achieve Normal Form?

1st Normal Form - example Test for 1NF: are there repeating groups of elements? If so, you must create a new entity. The new element will have a concatenated PK. For example: (OrderNr, ItemNr) Order Clump OrderNr ItemNr ItemName ItemPrice ItemQuantity ItemAmount ItemDescrip CustNr CustName CustAddress TotalAmount (The first grouping is Not in 1NF) Order OrderNr ItemNr ItemName ItemPrice ItemQuantity ItemAmount ItemDescrip Moving over elements to a new entity. This is 1NF. Some elements will be left in the old grouping, and groups may be further decomposed.

2nd Normal Form - example Test 2NF – do we have a partial dependency? Is it possible a non-key entity (ItemName) is dependent on one portion of the concatenated key (OrderNr, ItemNr), instead of on the whole? Example – if no one already ordered item ”z” then you cannot add the item. Some try to create a fake order to accommodate this, but can cause problems later. If 2NF test fails -> create a new entity Take a portion of the key that causes the violation to bring over to the new entity. (ItemName was only dependent on ItemNR.) – If an entity is in 1NF and it does not have a concatenated key, then it is already in 2NF. – If an entity fails 1NF, then you must test for 2NF. – ItemQuanity and ItemAmount are dependent on the whole order, so they should stay in the old entity. OrderNrItemNr 100a b c 200b r Item ItemNr ItemName ItemPrice ItemDescrip

3rd Normal Form - example Test 3NF: No non-key attributes can be dependent on another. Are there any? CustName is dependent on CustNr and is a violation of 3NF. Create a new entity. The PK of the new entity will be the non-key attribute of the old one that is really not non- key. CustNr must be a key. But now there is no longer a relationship between other groups (entities). So you need a foreign key (FK). CustNr becomes the PK in the new entity, and becomes the FK in the Orders attribute. The FK stores a pointer to where the data resides in the Customer table. CustNr Customer CustName CustAddress

3NF (side issues) Another violation, is if you have a derived data element. If you look at ItemAmount it is derived from ItemQuantity. (Q x P = A) So we take out ItemAmount. You can take out the derived entity, and then you have to calculate them each time you do a query. But, if you change price or change quantity, then you have to remember to change amount, which could cause integrity problems. We then have to add an element, OrderItemPrice that is diffferent from the ItemPrice, in case the quantity changes over time. It will then change the derived amount.

ERD Order (OrderNr, ItemNR) (PK) CustNr (FK)

ERD Items (ItemNr) (PK) -this is a simple PK (ItemNr, OrderNr) -are a complex FK

ERD Customer CustNr (PK) - this is a simple PK

Modellator 4.0 allows exporting a model to a database. Here only the script is exported. // S C R I P T F O R S t a n d a r d S Q L // Generated from Modelator :57:42 Model : Orders-Manage-simple-v2.mr4 // D R O P DROP TABLE Customer; DROP TABLE Order; DROP TABLE Items; // T A B L E S CREATE TABLE Customer ( CustNr INTEGER NOT NULL, CustName VARCHAR(25), CustAddress VARCHAR(75), PRIMARY KEY ( CustNr ) ); CREATE TABLE Order ( ItemNr INTEGER NOT NULL, OrderNr INTEGER NOT NULL, CustNr INTEGER, ItemQuantity INTEGER, OrderItemPrice DECIMAL(4,1), PRIMARY KEY ( ItemNr, OrderNr ) ); CREATE TABLE Items ( ItemNr INTEGER NOT NULL, OrderNr INTEGER NOT NULL, ItemName VARCHAR(25), ItemDescrip VARCHAR(75), ItemPrice DECIMAL(4,1), PRIMARY KEY ( ItemNr, OrderNr ) ); // F O R E I G N K E Y S ALTER TABLE Order ADD FOREIGN KEY ( CustNr ) REFERENCES Customer ( CustNr ); ALTER TABLE Items ADD FOREIGN KEY ( ItemNr, OrderNr ) REFERENCES Order ( ItemNr, OrderNr ); // I N D E X E S CREATE INDEX ItemNr ON Items ( ItemNr ASC ); // I N D E X E S O N F O R E I G N K E Y S CREATE INDEX FK1_Customer_Order ON Order ( CustNr ); // C O M M E N T S O N T A B L E S A N D C O L U M N S // G R A N T A C C E S S GRANT SELECT, INSERT, UPDATE, DELETE ON Customer TO PUBLIC; GRANT SELECT, INSERT, UPDATE, DELETE ON Order TO PUBLIC; GRANT SELECT, INSERT, UPDATE, DELETE ON Items TO PUBLIC;

You should be able to change the logical model when the physical world changes: Can add relations and entities/attributes later.. For example Sellers – add sellers information ItemCategory – add category codes Order –add order date May choose to remove derived values (e.g. Price * Quantity = Amount)