physical data modeling

25
MSc in Global Financial Information Systems (GFIS) Module: Data Modelling and Analysis Project Name: Physical Data Modelling (PDM) Abbas Ahmed (20026831)

Upload: abbas-ahmed

Post on 16-Jul-2015

68 views

Category:

Data & Analytics


0 download

TRANSCRIPT

Page 1: Physical data modeling

MSc in Global Financial Information Systems (GFIS)

Module: Data Modelling and Analysis

Project Name: Physical Data Modelling (PDM)

Abbas Ahmed (20026831)

Page 2: Physical data modeling

Contents 1. Introduction .............................................................................................................................. 3

2. Review and Amendments to the Conceptual & Logical Data Models............................................ 3

3. Entity Type, Attribute and Data Type ......................................................................................... 8

4. Domain Creation..................................................................................................................... 14

5. Attribute Domain Association.................................................................................................. 15

6. Physical Data Model ............................................................................................................... 19

7. Conclusion ............................................................................................................................. 21

8. Appendix ............................................................................................................................... 22

Page 3: Physical data modeling

1. Introduction

In the previous section we have completed the Logical Data Model (LDM). The LDM is the version

of the model that illustrates all of the business requirements of an organisation. The LDM contains all

the attributes, descriptions and definitions. The physical data model (PDM) is the complete model of

the database for the Life Insurance Company. This model will include all of the required tables,

columns, database properties, relationships for the physical implementation of the database.

Therefore the physical data model contains most of the objects present in the database. The model will

show the table name, column name, data type, null, not null, unique constraints, primary key

constraints, foreign key constraints which allow us to code them. The database performance can

utilise indexing strategy, physical storage and normalisation. These act as an important function of the

physical model. When the LDM is completed the development of the physical data model begins.

When the physical data model is completed it is sent to the technical teams for review. The evolution

from a logical data model to a physical will enforce database rules, integrity, super types and sub

types onto the database.

We will be making a series of changes to the LDM in order to craft it into a Physical data model

according to the requirements that were mentioned in the previous paragraph. In the case of our Life

Insurance database the purpose of the model will be for company use only. The company will utilise

the database in order to store customer data and carry out business analytics utilising the rich store of

information collected and processed by the system. To modify the Logical Data Model the descriptive

entity types of the LDM will be replaced by the technical language of the PDM. The LDM will

therefore will change for the storage and strategic analysis of customer data which will allow the

organisation to make better informed decisions and reduce duplicated data.

2. Review and Amendments to the Conceptual & Logical Data Models

In order to implement the PDM we have made amendments to our LDM which are listed below.

Customer

In the customer table we deleted the country attribute and we created a new entity type named

country. The reason for the change to the country attribute is because the country names can

be complex in nature so if we want to retrieve the data from the country attribute it can be

difficult. Hence by using the country ID it will be easier to find or change the country details.

Customer Assessment

We removed the table name Customer_Assessment. The reason for this is because we can

assess the customer details in quotation where customer information will be used to reject or

Page 4: Physical data modeling

accept the quotation. We can assess the customer on the information provided such as

address, contact number, date of birth etc.

Quotation_Issued

We created the table name Quotation_Issued which will keep the record of all the customers

who are accepted and issued a quotation price depending on the customer details.

Life_ Insurance _Policy

We replaced the table name Life_Insurance_Policy to Insurance. Insurance table will keep the

details of the insurance types, the terms and conditions and detail descriptions of the Life

insurance products.

Insurance_Issued

We created a new table named Insurance_Issued. This is table is used where the customer

wants to proceed with the quotation issued. It will include the details of all the insurance

issued, customer detail, buying source etc.

Buy_Source

We have created table name Buy_Source. This table will store all the information of the

source of the consumer purchase.

Invoice:

We have removed the table name Invoice. We will use Quotation as the receipt and payment

will be made on the basis of Quotation.

Payment

We have removed the Payment table. The reason for this was to eliminate further duplicated

information. We replaced payment with Payment_Method which will be used to keep the

record of different payment types and instalment payments. This will include payment types

such as card payments and online payments.

Bank_Details

We have created the table name Bank_Details in order to keep the record of all the bank

details such as IBAN, BIC of the customer who purchased the Insurance.

Debit_Card_Details

This table will be used to store all the card details such as card type, expiration name etc.

Claim_Paymnet

We has removed the table name Claim_Payment. All the claim payment details will be stored

in the table name Claim.

Claim_Category

We have removed the table name Claim_Category and all the claim types will be stored under

the table name Claim.

Page 5: Physical data modeling

Claim_Assessment

We have removed the table name Claim_Assessment. All the claim assessment will be made

under the table name Claim where we have the option to process the claim or reject the claim

on the basis of information available or the claim history.

Cash_Payment

Cash_Payment table has been removed from the model and all the cash payment will be

stored in the table name Payment_Method.

Online_Payment

Online_Payment has been removed from the model and details of all the online transactional

will be stored in the table name Payment_Methods.

Direct_Debit

Direct_Debit has been removed from the model and all the details of direct debits will be

stored in table name Bank_Details.

Discount

This table has been removed. Under the table name Quotation_Detail we have the option to

offer a discount to the customer on the basis of the number of years they have used the

insurance options or their insurance history.

Country

We have created the table name Country which will use to store information about the

country details of the customer. The reason to create this table is to reduce error in the system.

For example if the we want to update the details of customer country we can simply use the

country ID or code instead of typing the country name which can be complicated in terms of

spelling.

Subtypes

We have made significant changes to the entity relationships. Customer entity has a subtype

as an Indiviudal_Customer and Corporate_Customer. They share common information such

as phone numbers, addresses in the customer table. The customer table is the parent of the

individual and corporate customer. The Individual and corporate customers do not have

primary keys anymore. Another example of using subtypes is Payment_Method. The

Payment_Method has subtypes called Credit_Card,_Details and Debit_Card_Details and

Bank_Details.

Normalisation:

We used the normalisation process in our PDM model. We organised the columns and tables

in order to minimise the redundancy of data. In the normalisation process we have created a

table name Country which will store all the information about countries. We have created two

tables for quotation one called Quotation and Quotation_Issued in order to break down the

Page 6: Physical data modeling

large tables into more acute tables. Another firm of Normalisation is where we deleted three

tables named as Claim_Assessment, Claim_Category and Claim_Payment into one table

named Claim which has the same function as the other tables.

Data Types

We revised our LDM in order to reduce the size of the Column. Some columns do not require

big spaces. Example for Name we have given only Varchar(50) to the main field while

reducing the size of the column we can increase the performance of the database. Another

form of the data types is giving extra space for Customer numbers where we believe that in

future we can have the maximum number of customers in our database.

2.1 Relationships of Table

To create a Physical Data model we have used three types of relationships. The relationships are

illustrated in the table below.

Table name Connected table name Relationship type

Customer Individual_Customer

Corporate_Customer

Sub type

Customer Broker Non identifying

Customer Branch Non identifying

Employee Branch Non identifying

Country Customer Non identifying

Insurance_Issued Claim Identifying

Buy_Source Insurance_Issued Non identifying

Insurance_Issued Payment_Method Identifying

Payment_Method Debit_Card_Details

Bank_Details

Sub types

Payment_Method Receipt Identifying

Page 7: Physical data modeling

Customer Insurance Identifying

Insurance Quotation Non identifying

Quotation_Issued Insurance_Issued Non identifying

2.2 Logical Data Model vs Physical Data Model

Logical Data Model Physical Data Model Entity Table

Attributes Column Primary key Primary key constraint

Relationship Foreign key

Page 8: Physical data modeling

3. Entity Type, Attribute and Data Type

The table below shows the entity types, attributes and definition, MS Access Data Type and Oracle Data Type for the Physical Data Model. The entity types

and attributes are finalised after the amendments are made to the previous Logical Data Model.

Entity Type (Tables) Attribute (Columns) Attribute Definition MS Access

Data Type

Oracle Data

Type

Customer

Customer_ID Customer unique code INTEGER NUMBER

Street Partial address of customer TEXT VARCHAR(100)

City City TEXT VARCHAR(50)

County County TEXT VARCHAR(50)

User_Name Log in name chosen by customer for services provided online

TEXT VARCHAR(25)

Password Log in code chosen by customer for security purposes

TEXT VARCHAR(50)

Email Customer's contact Email TEXT VARCHAR(25)

Mobile_Number Customer's personal mobile contact number - up to 14 digits. This includes international clients.

INTEGER NUMBER(25)

Landline Customer's home contact number - up to 14 digits

INTEGER NUMBER(25)

Work_Phone Customer's work contact number - up to 14 digits INTEGER NUMBER(25)

Fax Customer's fax contact incase of any document needs to be sent/received by customer - up to 9 digits.

INTEGER NUMBER(25)

Emergency_Contact Customer's preferred choice of person to contact in case of emergency. E.g. accident. - up to 14 digits

INTEGER NUMBER(25)

Best_Time_To_Call This indicates the customer's preferred time to be call.

TEXT CHAR(9)

Corporate_Customer Customer_ID Unique code to indicate customer. INTEGER NUMBER

Page 9: Physical data modeling

Registration_Number Unique code upon corporate sign up of insurance policy to indicate which case and person in charge.

INTEGER NUMBER(25)

Business_Name Name of the corporation TEXT VARCHAR(50)

Business_Type Type of business TEXT VARCHAR(25)

Number_Of_Employees Number of employees whom signed up for the corporate insurance policy

INTEGER NUMBER(25)

Individual_Customer

Occupation Customer's occupation TEXT VARCHAR(25)

Maritial_Status This would be choice of Single, Married and separated. Indicates customer's marital status.

TEXT VARCHAR(15)

Number_Children Number of children in the family. INTEGER NUMBER(25)

Next_To_Kin Name and details of person to contact during emergency.

TEXT VARCHAR(50)

Nationality Customer's current nationality. TEXT VARCHAR(25)

Medical_Condition Indicates health status of the customer. This evaluates risk and current medical condition.

TEXT VARCHAR(225)

Residency_Period Period of stay in current residing country. INTEGER NUMBER(25)

Title This could be a choice of Mr, Ms, Miss and Dr. To indicate the title one wish to be address as.

TEXT VARCHAR(15)

First_Name Customer's first name TEXT VARCHAR(50)

Middle_Name Customer's middle name TEXT VARCHAR(50)

Last_Name Customer's surname TEXT VARCHAR(50)

Date_of_Birth Customer's date of birth. DATE/TIME DATE

Gender Customer's gender TEXT VARCHAR(6)

Disability Any disabilities faced by customer. TEXT VARCHAR(25)

Branch

Branch_ID Unique code to indicate specific branch. INTEGER NUMBER

Branch_Street Address of which the branch resides on. For ease of customer to locate the branch.

TEXT VARCHAR(100)

Branch_City City of which the branch resides on. For ease of customer to locate the branch.

TEXT VARCHAR(50)

Page 10: Physical data modeling

Branch_County County of which the branch resides on. For ease of customer to locate the branch.

TEXT VARCHAR(50)

Branch_Email Branch's contact Email. TEXT VARCHAR(50)

Branch_Phone Branch's contact number. INTEGER NUMBER(25)

Commission

Commission_ID Unique code to indicate commission given or not given.

INTEGER NUMBER

Commission_Amount Amount of commission pending/given. INTEGER NUMBER(9,2)

Broker_ID Unique code for external broker. INTEGER NUMBER

Broker

License_Number Broker's Licence number. INTEGER NUMBER(25)

License_Expiry Date of licence expiry for broker. DATE/TIME DATE

Broker_Name Name of insurance broker. TEXT VARCHAR(50)

Broker_Phone Broker's contact number. INTEGER NUMBER(25)

Broker_Email Broker's contact Email. TEXT VARCHAR(50)

Broker_Street Broker's address. This is to indicate which area is the broker available at.

TEXT VARCHAR(100)

Broker_City Broker's available city. TEXT VARCHAR(50)

Broker_County Broker's available county. TEXT VARCHAR(50)

Employee

Employee_ID Unique code for employee working for the internal employee.

INTEGER NUMBER

Employee_Name Employee's Name TEXT VARCHAR(50)

Employee_Designation Employee's current designation. TEXT VARCHAR(15)

Employee_Date_Of_Joining This indicates how many years of experience with the company.

DATE/TIME DATE

Employee_Ref_Number Case reference number. This refers to which case is the employee working on. It is gives the function to track back for any detail query by looking for the person in charge.

INTEGER NUMBER(25)

Insurance

Insurance_ID Unique code for insurance product ID INTEGER NUMBER

Insurance_Type This indicates the type of insurance. E.g. life insurance, mortgage insurance and etc.

TEXT VARCHAR(25)

Page 11: Physical data modeling

Description This gives a brief description what, how, when does this insurance functions.

TEXT VARCHAR(255)

Terms_Conditions This explains on the terms of coverage, year of coverage, process of application and other legal issues.

TEXT VARCHAR(255)

Quotation

Quotation_ID Unique code for quotation. INTEGER NUMBER

Fraud_Level Indicates the level of fraud of this policy. This is a test to notify check test to be conducted. Probably cause of extremely high amount issued.

TEXT CHAR(8)

Quotation_Status Indicates the status of the quotation. Once it is finalize, it will show the results such as pending, accept and reject status.

TEXT VARCHAR(15)

Insurance_Required_Years Years of insurance cover requested by customer. INTEGER NUMBER(25)

Smoker Indicates is the customer a smoker or non-smoker. It will be a selection of smoker or non-smoker upon filling in the details.

TEXT CHAR(3)

Claim_Years Claim within the last 5 years made by customer. This is a bonus discount if the customer has fewer claims or no claims within that time period.

INTEGER NUMBER(25)

Years_Insured Years of coverage by the previous policy. INTEGER NUMBER(25)

Previous_Insurance_Name Previous insurance policy held by customer. TEXT VARCHER(50)

Quotation_Detail Details on assessment sheet which is checked by employee in charge. This is for internal assessment and reference only.

TEXT VARCHAR(255)

Insurance_Issued

Insurance_Issued_ID Unique ID for insurance issued to customer. This will be the reference code for employee or broker which service the customer.

INTEGER NUMBER

Start_Date Starting date of the insurance coverage. DATE/TIME DATE

End_Date End date of insurance coverage. DATE/TIME DATE

Page 12: Physical data modeling

Claim

Claim_ID Unique ID for claims claimed by customer. This will be reference code for employee to allocate into the correct policy. For internal assessment only.

INTEGER NUMBER

Claim_Date Date of claim. DATE/TIME DATE

Claim_Type Type of claim. It is the choice of a table of possible claim type. E.g. accident, hospitalisation, operation and etc.

TEXT VARCHAR(25)

Claim_Amount Amount of claim requested. INTEGER NUMBER(9,2)

Amount_Given Amount of claim allowed after being accessed. INTEGER NUMBER(9,2)

Status Status of current assessment on claims and issuance of claims.

TEXT VARCHAR(15)

Reason Reason of allowing/rejection of claims. TEXT VARCHAR(255)

Claim_Processor_Reference_Number This indicates the reference number of whom was processing the claim. It will be the reference number of internal employee.

INTEGER NUMBER(25)

Payment_Method

Payment_Method_ID Unique code for payment method. INTEGER NUMBER

Payment_Type This indicates which type of payment the customer prefers. By card, cash or direct debit for recurring auto payment.

TEXT VARCHAR(15)

Receipt

Receipt_ID Unique code for receipt issued. INTEGER NUMBER

Total_Amount This indicates the amount due for the purchases made.

INTEGER NUMBER(9,2)

Amount_Received This indicates the amount received by the insurance company.

INTEGER NUMBER(9,2)

Balance This indicates the balance due after payment. This should show 0 if the customer had settle all the balances.

INTEGER NUMBER(9,2)

Receipt_Date Date of receipt issued. Receipt will be given out to customer as soon as it is dated.

DATE/TIME DATE

Bank_Detail

BIC 8 digit unique code for bank transfers. INTEGER NUMBER(25)

Owner_Name Name of issuer. TEXT VARCHAR(50)

Page 13: Physical data modeling

Bank_Name Name of paying bank. TEXT VARCHAR(50)

IBAN International Bank Account Number. 18 unique codes for international bank transfer.

INTEGER NUMBER(25)

Debit_Card_Details

Card_Number Credit card's unique 14 digit code. INTEGER NUMBER(25)

Owner_Name Name of the card owner. This is for internal reference purposes when payee is not the customer whom is purchasing.

TEXT VARCHAR(50)

Security_Code 3 digit unique code for authentication. INTEGER NUMBER(25)

Expiry_Date Date of expiry for the credit card. DATE/TIME DATE

Card_Type This is a selection of AMEX, VISA, MASTER etc. This is to clarify on which type of card the payee is using.

TEXT VARCHAR(15)

Buy_Source

Buy_Source_ID Unique code for purchase from employee or broker.

INTEGER NUMBER

Buy_Source_Type This indicates a choice of employee or broker. It is to track from which this policy is handled by.

TEXT CHAR(8)

Buy_Source_Reference/ License_Number

Reference code for employee or broker licence number to indicate which personnel is handling the particular policy. This is to ease the tracking of the policy.

INTEGER NUMBER

Quotation_Issued

Quotation_Issued_ID Unique code for quotation issued to customer. INTEGER NUMBER

Quotation_Amount Quotation amount given to customer after quotation assessment was made in Quotation request.

INTEGER NUMBER(9,2)

Quotation_Date Date of quotation done and issued to customer. DTAE/TIME DATE

Country

Country_ID Country Unique Code INTEGER NUMBER

Country Name Name of the country. This is to sort customers by country for the ease of finding them by country manager.

TEXT VARCHAR(50)

Page 14: Physical data modeling

4. Domain Creation

The validation rule for the domain is shown in the table below along with the logical data type.

The validation rule only applies for certain domain as some of the domains required valid values.

Domain Logical Data Type

Validation Rule

Identifier NUMBER

Currency NUMBER(9,2)

Number NUMBER(25)

Number of Year INTEGER

Password VARCHAR(25)

Date DATE

City VARCHAR(50)

County VARCHAR(50)

Country VARCHAR(50)

Name VARCHAR(50)

Email VARCHAR(50)

Phone VARCHAR(15)

Street VARCHAR(100)

Designation VARCHAR(15)

Occupation VARCHAR(25)

Marital Status VARCHAR(15) List of marital status valid values consisting of single, married, separated and divorce.

Nationality VARCHAR(25)

Title VARCHAR(15) List of Title valid values consisting of Mr, Mrs, Miss and Dr.

Gender VARCHAR(6) Valid values of Male and Female.

Disability VARCHAR(25) Simple valid values of Yes or No.

Comment VARCHAR(255)

Status VARCHAR(15) Three valid values for the claims: approve, reject, pending.

Payment Type VARCHAR(15) List of Payment Type valid values consisting of online payment, cash payment and direct debit.

Card Type VARCHAR(15) List of Card Type valid values consisting of Debit, Visa Debit, American Express, Credit Card and Mastercard.

Business Type VARCHAR(25)

Claim Type VARCHAR(25)

Fraud Level CHAR(8) Valid values recording the fraud level consisting of level 1, level 2 and level 3.

Insurance Type VARCHAR(25)

claim/insured years

NUMBER The valid value which represent the number of years consisting 1, 2, 3, 4 and 5.

buy source type CHAR(8) The buy source type refers to either the employee or broker.

Page 15: Physical data modeling

5. Attribute Domain Association

Each of the attributes in the E-R diagram is associated with a domain, as shown in Table below. A same domain can be used for more than one attribute.

BRANCH Domain

Branch ID identifier

city city

county county

email email

phone phone

street street

CUSTOMER Domain

Customer ID identifier

street street

city city

county county

user name name

password password

email email

mobile number phone

landline phone

work phone phone

fax phone

best time to call number

emergency contact phone

COMMISSION Domain

Commission ID identifier

commission amount currency

BROKER Domain

Broker ID identifier

license number number

license expiry date

broker name name

broker phone phone

broker email email

broker city city

broker county county

broker street street

Page 16: Physical data modeling

EMPLOYEE Domain

Employee ID identifier

employee name name

employee designation designation

employee date of joining date

employee reference number

number

COUNTRY Domain

Country ID identifier

country name name

CORPORATE

CUSTOMER

Domain

registration number number

business name name

business type business type

number of employee number

CORPORATE

CUSTOMER

Domain

registration number number

business name name

business type business type

number of employee number

INDIVIDUAL

CUSTOMER

Domain

occupation occupation

marital status marital status

number of children number

next to kin name

nationality nationality

medical condition status

residency period number of year

title title

first name name

last name name

middle name name

date of birth date

gender gender

Disability disability

Page 17: Physical data modeling

INSURANCE Domain

Insurance ID identifier

insurance type insurance type

description comment

terms conditions comment

QUOTATION Domain

Quotation ID identifier

claim years claim/insured years

years insured claim/insured years

previous insurance name name

quotation details comment

smoker date

insurance required years comment

quotation status status

fraud level comment

QUOTATION ISSUED Domain

Quotation Issued ID identifier

quotation amount currency

quotation date date

INSURANCE ISSUED Domain

Insurance Issued ID identifier

start date date

end date date

claim bonus number of year

CLAIM Domain

Claim ID identifier

claim date date

claim type claim type

claim amount currency

amount given currency

claim status status

reason comment

PAYMENT METHOD Domain

Payment Method ID identifier

payment type payment type

Page 18: Physical data modeling

DEBIT CARD DETAIL Domain

card number number

owner name name

security code number

expiry date date

card type card type

BANK DETAIL Domain

BIC number

owner name name

bank name name

IBAN number

RECEIPT Domain

Receipt ID identifier

total amount currency

amount received currency

balance currency

receipt date date

BUY SOURCE Domain

Buy Source ID identifier

buy source type buy source type

buy source reference/license number

number

Page 19: Physical data modeling

6. Physical Data Model

The ERD diagram of the Physical Data Model is shown separately below:

Physical Data Model (part 1)

Page 20: Physical data modeling

Physical Data Model (part 2)

Page 21: Physical data modeling

7. Conclusion

The PDM and the oracle codes have now have been completed. The conversion of the LDM to the

PDM allows the database to be utilised for practical use and analysis. The Physical Database will

allow structured queries to be drawn from the completed model allowing complex analytics to

perform on the database. In the 21st century world of commerce the stronger the quality and quantity

of information through business analytics will allow the business to make better informed decisions

and possibly anticipate future trends if used correctly. The advancement of the basic CDM to PDM is

the evolution of new competitive advantage and form of leverage to defeat potential competition and

improve decisions within the business.

Page 22: Physical data modeling

8. Appendix

Conceptual Data Model

Page 23: Physical data modeling

Logical Data Model (part 1)

Page 24: Physical data modeling

Logical Data Model (part 2)

Page 25: Physical data modeling