Objective To translate E-R diagram in creating a table. Learning outcome. Students would be able to create and instantiate a table

Transcription

1 28 th September 2017

2 Objective To translate E-R diagram in creating a table Learning outcome Students would be able to create and instantiate a table

3 Physical design /Model (Creating Tables)

4 BUILDING CONSTRUCTION BUILDING STRUCTURE: Pillars and concrete works forms the skeleton/schema/structure BLOCK LAYING: Block laying is done to divide rooms and make use of doors to link relationship between Chamber-Hall, Storekitchen, Toilet-Bath. You can Modify a hall & dinning to have partition when eating)- Normalisation SECURITY/PORTAL POST: Portal-inn serves as interface between visitors and tenants of a hostel or apartment. A visitor has to use the intercom/interface service at the reception to locate hostel rooms (fields); avoiding knock of doors to disturb asleep tenants. ROOM DEFINITION: The architect and mason design some rooms for specific items/activity or purpose unless reconstruction. Toilet room cannot be use as rest room. (Keys for Doors. PIANTING & DECORATION: painting and décor is the last part of the construction DATABASE CONSTRUCTION DATABASE TABLE: Translating the E-R diagram to Create a Table is the physical schema/structure of the database RELATIONSHIP BETWEEN TABLES: Creating Relationship between common tables is key. It is a must to divide tables based on unique entities and their attributes. At best (2) entities should not be on one table. You can rearrange some data on other tables FORMS: Create a form as interface or portalinn to communicate to various fields (rooms) on the table. The form helps easy tracking of a field on the table than physically moving around the table to update/delete/edit/add an entry on the table. It reduces error entry. DATATYPE DEFINITIONS: Some fields are defined to hold numeric values only. Such fields will not accept alphabets or alphanumeric. (Primary Key & foreign key fields ) FORM INTERFACE DÉCOR: You may no add things such as logo, picture and feedback

5 After the Building: Operations Building Operation ACCEPTING TENANTS ENTRY: Allow tenants to come in and occupy hostel/apartment QUERY: A Landlord may want to know how many married couples are in the house. To calculate how many months for tenancy agreement renewal of MR. A? How many children in the house? How many childrenboys & girls in each apartment etc. REPORT: If a landlord gather data after the query, he/she can present the report to rent control for any administrative procedure. Database operations/instantiate DATA ENTRY: Records can now be entered and stored in appropriate defined field QUERY: The same thing applies in database. Data queries are in question format. How many customers are from Ashanti region? How many customers are called Prince? You can store routine queries in the system for fast performance on repetitive operation. REPORT: after a query, you can generate a report and print out on hardcopy for any administrative purpose. You can vary the presentation format/appearance of the report to suit interest.

6 Physical modeling involves the actual design of a database according to the business needs/requirements that were established during logical modeling stage (4) on SDLC. During physical modeling, objects such as tables and columns are created and the size of the table is based on entities and attributes defined during logical modeling. All building materials are available to start the construction. Output/Deliverables after completion of Logical Modeling (Stage-4) 1. Table/Server model diagram: This field work model shows tables, columns, and relationships within a database. 2. User feedback documentation from Alpha & Beta Testing 3. Database design documentation: Produce codes, maintenance manual & End user manual/help document.

7 Codds Rule 1 Table format : Develop & Store Related data in Rows & Columns. Physical model involves the Actual development of a database according to the requirements that were established during logical modeling. At this stage, objects such as tables and columns are created based on entities, attributes & domains.

8

9 Basic Steps: Build a table for each entity set (All persons, All Dept. etc) Create column for each attribute in the entity set Indivisibility/Atomicity Rule and Ordering Rule. i.e make each attribute represent one thing/value. Create Primary Key to identify each entity uniquely

10 SID Name SSN Name Student Advisor Professor Major GPA Dept SID Name Major GPA 1234 Noah INFS Mercy PCH 3.6 Save table name/title as Student SSN Name Dept 9999 John Math 8888 Janet INFS Save table name/title as Faculty/lecturer

11 Weak Entity Set Cannot exists alone To build a table/schema for weak entity set Construct a table with one column for each attribute in the weak entity set Remember to include discriminator Augment one extra column on the right side of the table, put in there the primary key of the Strong Entity Set (the entity set that the weak entity set is depending on) Primary Key of the weak entity set = Discriminator + foreign key

12 SSN Name Age Name Professor owns Children Dept * Primary key of Children is Parent_SID + Name Age Name Parent_SSN 10 Bernard Martha 8888

13

14 Single Entity Table (Empty fields) SID SName SAge SClass SSection

15 Single Entity Table (Data Entry in Fields)

16 Simple: Relational Model is made up of Tables! Row in a Table = Tuple/a relational instance (holds data) Column in a Table = Attribute A table = Relation/schema (Awaits data storage) Cardinality = number of rows Degree = number of columns Field = Cell/memory located space holding specific datatype Tuple/relational instance Field Attribute SID Name Major GPA 1234 John CS Mary EE 3.6 Cardinality = 2 4 Degree

17

18 Major Activities in each model Feature Conceptual Logical Physical Entity Names Entity Relationships Attributes Primary Keys Foreign Keys Table Names Column Names Column Data Types

19

20

21 Types of Relationships Weak relationship Also known as a non-identifying relationship, exists if the PK of the related entity does not contain a PK component of the parent entity. By default, relationships are established by having the PK of the parent entity appear as an FK on the related entity (implemented in right picture). Strong relationship Also known as an identifying relationship, exists when the PK of the related entity contains a PK component of the parent entity (implemented in left picture). Recursive relationship A recursive relationship is one in which a relationship can exist between occurrences of the same entity set (Naturally, such a condition is found within a unary relationship). 21

22 Categories of Relationships One-to-One When both participants can have only one instance of each other. (less used but stable). For Example, HUSBAND can have only one WIFE and WIFE can have only one HUSBAND. This is 1:1 relationship between HUSBAND and WIFE participants. One-to-Many When one participant can have multiple instances of other participants but other participant can have only one instance of first participants. (mostly used and stable). For Example, CUSTOMER may generate many ORDERs but each ORDER is generated by one CUSTOMER. This is 1:M relation between CUSTOMER and ORDER. Many-to-Many When both participants can have multiple instances of each other. (not practice). For Example, STUDENT can be enrolled in many SUBJECTs and one SUBJECT can be chosen by many STUDENTs. This is M:M relation between STUDENT and SUBJECT. 22

23

24 Relationships (1:1) Implementation (2) Following is implementations for 1:1 relationship. One table has PK and other table must have same PK as well as FK. Department Table has Department_ID as PK. And Manager Table must have Department_ID as PK as well as FK (You can change the name of column but it should have same data). 19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 24

25 Relationships (1:M) - Implementation The common column is DEPARTMENT_ID (which is the primary key in the DEPARTMENT table) should be as a foreign key in the EMPLOYEE table. One individual DEPARTMENT_ID can relate to many rows in the EMPLOYEE table. Business Rule for this is: one department can relate to one or many employees (or even no employees) and that an employee is associated with only one department (or, in some cases, no department). 19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 25

26 Relationships (M:N) Implementation (1) Consider the EMPLOYEE and PROJECT tables. The business rule is as follows: One employee can be assigned to multiple projects, and one project can be supported by multiple employees. Therefore, it is necessary to create an M:M relationship to link these two tables. In the relational database we don t implement the M:N relation by just giving FKs to each other and the reason is we don t want two sided links (circles). So, we create a new entity called Bridge Entity and its PK is a composite key made up with PKs of both tables. It may or may not have any other attributes but composite key is must. After doing this, there becomes two 1:M relations. 1. One between Bridge and EMPLOYEE table (1:M). 2. One between Bridge and PROJECT table (1:M). 19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 26

27 Relationships (M:N) Implementation (2) In this example we made Bridge Table under name EMPLOYEE_PROJECT containing PKs of both above tables. It has one more attribute for some extra information. Now, it becomes like this and we have three tables now. 19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 27

28