d_pdm_report

Physical Data Model

Data Mining System For a Bank

Names: Lee Rock, Richard Olayele Awosika, Sharath KC, Johnny Syllias

Student Numbers: 20038860, 20072896, 20069626, 20072774

Department: Department of Graduate Business

Course: MSc in Global Financial Information Systems

Module: Data Modelling and Analysis

Project Manager: Johnny Syllias

Presented To: Dr Aidan Duane

Assignment 3 of 3

Group: D

We firmly declare that this assignment was completed by our own accord and to the best of our abilities in accordance with the plagiarism regulations and in line with the standards of academia set out by Waterford Institute of Technology.

Contents1.0 Introduction.....................................................................................................................................1

1.1 Definitions...................................................................................................................................1

1.2 Definition of Abbreviations..........................................................................................................2

1.3 Overview......................................................................................................................................3

2.0 Business Assumptions......................................................................................................................3

3.0 Database Rules................................................................................................................................4

4.0 Physical Dictionary...........................................................................................................................5

5.0 Primary and Foreign Key Dictionary...............................................................................................23

6.0 Domain Dictionary.........................................................................................................................26

7.0 Alterations and Modifications Logical Data Model........................................................................30

8.0 DDL Code Test for Oracle and Access............................................................................................30

9.0 Oracle DML Query Test..................................................................................................................32

9.1 Test DML Query 1......................................................................................................................32

9.2 Test DML Query 2......................................................................................................................33

9.3 Test DML Query 3......................................................................................................................34

10.0 Entity Relationship Diagram........................................................................................................34

11.0 Conclusion...................................................................................................................................38

FIGURE 1 ORACLE FOREIGN KEY ERROR..............................................................................................................31FIGURE 2 ACCESS EMPLOYER ADDRESS ERROR...................................................................................................31FIGURE 3 BANKING DATA MINING SYSTEM AT CDM LEVEL.................................................................................35FIGURE 4 BANKING DATA MINING SYSTEM AT LDM LEVEL.................................................................................36FIGURE 5 BANKING DATA MINING SYSTEM AT PDM LEVEL.................................................................................37

TABLE 1 PHYSICAL DICTIONARY...........................................................................................................................22TABLE 2 PRIMARY AND FOREIGN KEY DICTIONARY.............................................................................................25TABLE 3 DOMAIN DICTIONARY............................................................................................................................29

1.0 Introduction

1.1 Definitions Attributes: The essential facts that is stored regarding each entity.

Cardinality: The maximum requirement in a relationship.

Conceptual Data Model (CDM): a skeleton or high level preliminary data model which is

intended to show a particular system may function.

Data Definition Language (DDL): Structured query language associated with creating,

updating and maintaining entities

Data Manipulation Language: (DML): Structured query language associated with

selecting, updating, deleting, manipulating and changing data in the entities.

Data Type: A category of data used to describe a number of similar sets of data e.g. a

number is a data type and an integer is a sub type of the number data type

Degree: Type of entity relationship.

DMS: Data mining system, a system to enable the capture, storage, classification and

clustering of information.

Entity: A particular subject or object in which data is stored regarding this subject or object

for example, customers. Entities are seen as tables in a database.

Entity Relationship Diagram: A diagram which shows the relationship between tables in

the database and depending on the type of diagram may also show attributes, foreign/primary

keys and a description of the relationships.

Entity Type: A category of a subject or object in which data is collected regarding for

example a customer is an entity while a set of customers is an entity type.

Foreign Key: A minimal set of attributes in a table used to form a connection or a

relationship between the original table and another table. The value of the primary key in one

table is the value of the foreign key in the other table.

1

Logical Data Model (LDM): Detailed data model indicating proposed attributes, foreign

keys, primary keys and the relationships between the entities.

Normalisation Normal Form 1 (NF1): A model is in its first normal form if it contains only

atomic values and there are no repeating groups.

Normalisation Normal Form 2 (NF2): A model is in its second normal form if the model is

in its first normal form and all attributes are dependent on the primary key.

Normalisation Normal Form 3 (NF3): a model is in its third normal form if the model is in

its second normal form and there is no transitive functional dependency.

Optionality: The minimum requirement in a relationship.

Record: A collection of fields and their values. Each record stores information i.e. the

attributes on a particular entity within an entity type. Records are sometimes called rows.

Relationship: the type of connection between one table and another.

Primary Key: An attribute or identifier that uniquely identifies a particular record. A

concentrated primary key has only one attribute where as an atomic primary key has multiple

attributes. A candidate primary key is an attribute(s) which could be selected as a primary

key.

Structured Query Language: an international standard for database manipulation used to

derive and alter information in a database.

Physical Data Model (PDM): A representation of the proposed database which takes into

account tables, columns of the tables, including datatypes and constraints, primary keys,

foreign keys and relationships between tables.

1.2 Definition of Abbreviations CDM: Conceptual Data Model

DDL: Data Definition Language

DML: Data Manipulation Language

ERD: Entity Relationship Diagram

LDM: Logical Data Model

2

NF1: Normalisation Normal Form 1



PDM: Physical Data Model

RDBMS: Relational Database Management System

SQL: Structured Query Language

1.3 OverviewContinuing on from the logical data model (LDM), the physical data model (PDM) aims to

finalise the structure of the database and to essentially generate the main body of the system

before testing end user testing and putting the system live. The physical data model will

transform the theoretical entities into tables and attributes into columns incorporating their

datatypes and constraints. This will be executed by developing the data definition language

(DDL) code, a category of structured query language (SQL) for both an Oracle and Microsoft

Access database. The PDM will incorporate changes and recommendations that were made at

the LDM presentation and feedback session held on the 16th of November 2015. Meeting

minutes for the entire project from CDM to PDM level can be found in Appendix E.

2.0 Business AssumptionsBusiness assumptions were rectified at CDM level and further analysed at LDM level; no

changes have been made to these assumptions at the PDM level. These assumptions include:

The company is a commercial bank that only trades with individuals rather than

companies.

Bank only trades in Euro currency.

Clients must have at least one deposit account.

All customer costs e.g. registration fees, interest etc. are included in the full

instalment/payment price and will not be differentiated out.

No late payment option, if the client misses a payment they will pay on the next

instalment date.

3

3.0 Database RulesThe following rules were implemented at CDM level in an effort to ensure data integrity and

consistency in order to limit data redundancy and maximise the potential for a functioning

model. No changes have been made to the database rules at LDM level. The PDM level has

incorporated one change to the database rules. These rules are as follows (the obsolete rule

has been marked with a line though the statement):

All entity names are coded with “GD” (case sensitive) before the actual entity name to

clarify that these tables are owned by GFIS Data Modelling and Analysis Group D

2015 e.g. GDClientDetail.

All entity names must begin with a capital letter and have no spaces between each

word in the name e.g. GDBuyToLetMortgageDetail.

Any table that provides a description must be identified with the word “Detail” at the

end of the name e.g. GDAutoInsuranceDetail.

Any table which records payments or non-payments for products the banks provide

must have “transactions” at the end of their name e.g. GDAutoInsuranceTransactions.

Any table which records payments or non-payments for products must have “Trans”

at the end of their name e.g. GDAutoInsuranceTrans.

All primary keys must be labelled with “ID” (case sensitive) after the name e.g.

ClientID.

4

4.0 Physical DictionaryThe following table identifies each entity along with a description of the entity purpose as well as the name, domain type, datatype for Oracle

11g and Microsoft Access, null option type and a definition of purpose for each attribute within its respected entity. Some alterations have been

made to the Oracle and Access datatypes in order to insure a more accurate capture and format of certain data. Any attribute with a “PURPOSE”

domain has had their Oracle datatype changed from VARCHAR2 (255) to CLOB to allow for greater intake of data for that respective attribute

(up to eight terabytes). In corresponding fashion, the same attributes have had their access datatypes changed from TEXT (255) to MEMO in

order to allow a greater intake of data. Attributes that require a currency value input have had their Oracle datatype changed from DECIMAL

(15,4) to NUMBER(15,4) which will ensure the system can capture 15 digits to the left of the decimal and 4 digits to the right; as opposed to the

decimal format which may not give the desired output as identified by the feedback session on the 16 th of November 2015. A gender Attribute

was also added to the model in the GDClientDetail table as the attribute was determined as relevant to the model. PI_Tenure was updated to

PITenure as the name of the attribute violated the database rules.

Entity Name : GDAutoInsuranceDetailEntity Definition : Data regarding auto insurance details of clients

Attribute Name Oracle Datatype Access Datatype Domain

Null Option Type

Attribute Definition

CPID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the client product table, i.e. its unique identifier

ClientID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the client detail table, i.e. its unique identifier

PLID VARCHAR2(20) TEXT(20) ID NOT NULL


AIValue NUMBER(15,4) CURRENCY AMOUNT NULL The value in euros of the client's auto insurance contract

AIVehicleType CHAR(18) TEXT(18) VEHICLETYPE NOT NULL

The type of vehicle that the client wishes to insure

5

AIRegistrationNumber VARCHAR2(50) TEXT(50) VEHICLEREGNUMBER NOT NULL

The registration number of the client's vehicle that they wish to insure

AIVehicleFinance VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The financing model currently in use for the vehicle that the client wishes to insure

AITenure INTEGER INTEGER TENURE NOT NULL

Time period of the client's auto insurance contract

AIInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULL Amount in euros that the client must pay on the instalment date

AIInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

The type of instalment the client wishes to utilise to repay the auto insurance

AIPaymentType CHAR(18) TEXT(18) PAYTYPE NOT NULL

The type of payment the client wishes to use to repay the auto insurance

AIRenewalDate DATE DATETIME DATETIME NULLThe date that the client's auto insurance contract is due to be renewed

AIFullLicence CHAR(3) TEXT(3) YESNO NOT NULL

Has the client a full licence (YES/NO)

AIVehicleModel CLOB MEMO PURPOSE NOT NULL

The model of the vehicle the client wishes to insure

Entity Name : GDAutoInsuranceTrans

Entity Definition : Data regarding auto insurance payment and non-payment by clients


Null Option Type


AITID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the auto insurance transaction table, i.e. its unique identifier

AIDr NUMBER(15,4) CURRENCY AMOUNT NULLThe amount of instalment the client paid on the instalment date for the their auto insurance

AICr NUMBER(15,4) CURRENCY AMOUNT NULL The amount of the instalment the

6

client did not pay on the instalment date for their auto insurance

AIDate DATE DATETIME DATETIME NULLThe date for which the payment or non-payment took place for the client's auto insurance







Entity Name : GDAutoLoanDetailEntity Definition : Data regarding auto loan detail of clients


Null Option Type








ALValue NUMBER(15,4) CURRENCY AMOUNT NULL The value in euros of the client's auto loan

ALVehicleType CHAR(18) TEXT(18) VEHICLETYPE NOT NULL

The type of vehicle that the client wishes to secure the auto loan for

ALVehicleModel VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The model of the vehicle that the client wishes to take out the auto loan for

ALRegistrationNumber VARCHAR2(50) TEXT(50) VEHICLEREGNUMBER NOT NULL

The registration number of the vehicle if applicable that the client wishes to take out the auto loan for

ALInsurance CHAR(3) TEXT(3) YESNO NOT NULL

Whether or not the client has taken out auto insurance for the vehicle

ALGuarantors VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

Individual(s) who have guaranteed the client's auto loan

7

ALInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

The type of instalment which the client chooses repay the auto loan

AlInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULLThe value in euros for which the client must pay on the instalment date for the auto loan

ALTenure INTEGER INTEGER TENURE NOT NULL

The time period of the client's auto loan

ALFullLicence CHAR(3) TEXT(3) YESNO NOT NULL

Has the client a full licence (YES/NO)

Entity Name : GDAutoLoanTransEntity Definition : Data regarding auto loan payment and non-payment by clients


Null Option Type


ALTID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the auto loan transaction table, i.e. its unique identifier

ALDr NUMBER(15,4) CURRENCY AMOUNT NULLThe amount of instalment the client paid on the instalment date for the their auto loan

ALCr NUMBER(15,4) CURRENCY AMOUNT NULLThe amount of instalment the client did not pay on the instalment date for the their auto loan

ALDate DATE DATETIME DATETIME NULLThe date for which the payment or non-payment took place for the client's auto loan







Entity Name : GDBuyToLetmortgageDetailEntity Definition : Data regarding buy to let mortgage detail of clients


Null Option Type


8







BTLFirstTime CHAR(3) TEXT(3) YESNO NOT NULL

Is the client a first time buy to let mortgage user (YES/NO)

BTLPropertyType CHAR(20) TEXT(20) PROPERTYTYPE NOT NULL

Type of property upon which the buy to let mortgage is based

BTLValue NUMBER(15,4) CURRENCY AMOUNT NULL Value in euros lent to client for the buy to let mortgage

BTLIInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULLThe amount to be paid at each instalment date for the buy to let mortgage

BTLInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

Type of instalment the client wishes to utilise to repay the buy to let mortgage

BTLPayType CHAR(18) TEXT(18) PAYTYPE NOT NULL

Payment type the client chooses to repay the buy to let mortgage

BTLAddress VARCHAR2(255) TEXT(255) ADDRESS NOT NULL

The address of the property which the buy to let mortgage is located

BTLCityTown VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The City or town upon which the property for the buy to let mortgage located

BTLCounty VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The County upon which the property for the buy to let mortgage located

BTLProvince VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The Province upon which the property for the buy to let mortgage located

BTLCountry VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The Country upon which the property for the buy to let mortgage located

BTLTenure INTEGER INTEGER TENURE NOT NULL

Time period of the client's buy to let mortgage

BTLPaymentType CHAR(18) TEXT(18) PAYTYPE NOT NULL

Type of payment upon which the client has chosen to pay back the

9

buy to let mortgage

BTLGuarantors VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

Individual(s) who have guaranteed the client's buy to let mortgage

BTLPropertyDescription CLOB MEMO PURPOSE NOT NULL

A description of the client's intended property for the buy to let mortgage

Entity Name : GDBuyToLetmortgageTransEntity Definition : Data regarding buy to let mortgage payment and non-payment by clients


Null Option Type


BTLTID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the buy to let mortgage transaction table, i.e. its unique identifier.

BTLCr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of the instalment which the client did not pay on the instalment date for their home owner mortgage.

BTLDr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of the instalment which the client paid on the instalment date for their home owner mortgage.

BTLDate DATE DATETIME DATETIME NULLThe date for which the payment or non-payment took place for the client's buy to let mortgage.




Primary key of the client detail table, i.e. its unique identifier.



Entity Name : GDClientDetailEntity Definition : Data regarding initial and miscellaneous information regarding clients


Null Option Type


ClientID VARCHAR2(20) TEXT(20) ID NOT Primary key of the client detail

10

NULL table, i.e. its unique identifier

Forename VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL The first name of the client.

Surname VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL The last name of the client.

Gender CHAR(18) CHAR(18) GENDER NULL The gender that the individual identifies by

DOB DATE DATETIME DATETIME NULL The client's date of birth.

Address VARCHAR2(255) TEXT(255) ADDRESS NOT NULL

The current home residence of the client.

CityTown VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The current city or town the client resides in.

County VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The current county the client resides in.

Province VARCHAR2(100) TEXT(100) GENERALNULL NULL The current province the client resides in.

Country VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The current country the client resides in.

HomePhone LONG LONG PHONE NULL The home phone number of the client.

WorkPhone LONG LONG PHONE NULL The work phone number of the client.

Mobile LONG LONG PHONE NULL The mobile number of the client.Email VARCHAR2(100) TEXT(100) EMAIL NULL The email address of the client.

Profession VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL The occupation of the client.

Employer VARCHAR2(100) TEXT(100) GENERALNULL NULL The entity/firm/business/company who is the client’s employer.

EmployerAddress VARCHAR2(100) TEXT(100) EMPLOYERADDRESS NULLThe address of the entity/firm/business/company of the client employer

AnnualSalary MONEY MONEY GENERALNULL NULL The gross annual income in euros of the client.

MaritalStatus CHAR(20) TEXT(20) MARTIALSTATUS NULL The relationship status of the client.

Ethnicity VARCHAR2(100) TEXT(100) GENERALNULL NULL The race of the client.

ReligiousAffiliation VARCHAR2(100) TEXT(100) GENERALNULL NULL The religion if applicable the client identifies with.

11

MaleChildren INTEGER INTEGER NUMBER NULLThe number of male children under the personal care of the client

FemaleChildren INTEGER INTEGER NUMBER NULLThe number of female children under the personal care of the client.

InfoUseOptIn CHAR(3) TEXT(3) YESNO NOT NULL

Expressing if the bank is allowed to use the client's personal information for marketing purposes.

ClientActive CHAR(3) TEXT(3) YESNO NOT NULL

Identifies whether or not the client is an active participating member of the bank.

Entity Name : GDClientProductsEntity Definition : Stores information regarding the active and inactive products the client has used


Null Option Type








CPActive CHAR(3) TEXT(3) YESNO NOT NULL

Determines whether or not a particular product of a particular client is in use or not use

Entity Name : GDDepositAccountDetailEntity Definition : Data regarding the desposit accounts of clients


Null Option Type






PLID VARCHAR2(20) TEXT(20) ID NOT Primary key of the client detail

12

NULL table, i.e. its unique identifier

GADCategory CHAR(12) TEXT(12) DEPACCCATEGORY NOT NULL

The category of the deposit account (current/savings)

GADAccType CHAR(18) TEXT(18) DEPACCTYPE NOT NULL

The type of (current/savings) deposit account

Entity Name : GDDepositAccountTransEntity Definition : Data regarding the transactions to and from deposit accounts of clients


Null Option Type


DATID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the deposit account transaction table, i.e. its unique identifier

GADTDate DATE DATETIME DATETIME NULL Date upon which the transaction took place

GADTNarration CLOB MEMO PURPOSE NOT NULL Description of the transaction

GADTDeposits NUMBER(15,4) CURRENCY AMOUNT NULL Amount in euros for which the client transferred into their account

GADTWithdrawals NUMBER(15,4) CURRENCY AMOUNT NULL The amount in euros for which the client took out of their account







Entity Name : GDEducationalLoanDetailEntity Definition : Data regarding educational loan detail of clients


Null Option Type



Primary key of the client product table, i.e. its unique identifier.



13



ELValue NUMBER(15,4) CURRENCY AMOUNT NULL The value in euros for which the client's education loan.

ELEducationType VARCHAR2(10) TEXT(10) EDUCATION NULL The type of education the client's education loan is being used for

ELSchoolAddress VARCHAR2(255) TEXT(255) ADDRESS NOT NULL

The address of the education centre the client is attending.

ELSchoolCityTown VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The city or town of the education centre the client is attending

ELSchoolCounty VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The county of the education centre the client is attending.

ELSchoolProvince VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The province of the education centre the client is attending

ELSchoolCountry VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

The country of the education centre the client is attending.

ELLivingAtHome CHAR(3) TEXT(3) YESNO NOT NULL

Is the client living in their primary or temporary residence (YES/NO)

ELPreviousEducation VARCHAR2(10) TEXT(10) EDUCATION NULL The most recent education level attained by the client.

ELInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

The type of instalment the client wishes to utilise to repay their educational loan.

ELInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULLThe amount in euros the client must pay on the instalment date for their educational loan.

ELPaymentType CHAR(18) TEXT(18) PAYTYPE NOT NULL

The payment type the client wishes to utilise in order to repay their educational loan.

ELTenure INTEGER INTEGER TENURE NOT NULL

The Time period of the client's educational loan

ELGuarantors VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

Individual(s) who have guaranteed the client's educational loan

Entity Name : GDEducationalLoanTransEntity Definition : Data regarding educational loan payment and non-payment by clientsAttribute Name Oracle Datatype Access

DatatypeDomain Null

Option Attribute Definition

14

Type

ELTID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the educational loan transaction table, i.e. its unique identifier

ELDr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of the instalment which the client paid on the instalment date for the their educational loan

ELCr NUMBER(15,4) CURRENCY AMOUNT NULLThe amount of the instalment the client did not pay on the instalment date for the their educational loan

ELDate DATE DATETIME DATETIME NULLThe date for which the payment or non-payment took place for the client's educational loan







Entity Name : GDHealthInsuranceDetailEntity Definition : Data regarding health insurance detail of clients


Null Option Type








HIValue NUMBER(15,4) CURRENCY AMOUNT NULL The value in euros of the client's health insurance contract

HITenure INTEGER INTEGER TENURE NOT NULL

The Time period of the client's health insurance contract.

HIInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULL The amount in euros that the client must pay on the instalment date.

15

HIInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

The type of instalment the client wishes to utilise to repay their health insurance

HIPaymentType CHAR(18) TEXT(18) PAYTYPE NOT NULL

The type of payment the client wishes to utilise to pay for the health insurance

HIMedicalReport CHAR(3) TEXT(3) YESNO NOT NULL

Has the client submitted a medical report for the health insurance contract (YES/NO)

HIRenewalDate DATE DATETIME DATETIME NULL The client's date of renewal for their health insurance contract.

Entity Name : GDHealthInsuranceTransEntity Definition : Data regarding health insurance payment and non-payment by clients


Null Option Type


HITID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the health insurance transaction table, i.e. its unique identifier

HIDr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of instalment for which the client paid on the instalment date for the their health insurance

HICr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of the instalment which the client did not pay on the instalment date for the their health insurance

HIDate DATE DATETIME DATETIME NULLThe date for which the payment or non-payment took place for the client's health insurance







Entity Name :

16

GDHomeOwnerMortgageDetailEntity Definition : Data regarding home owner mortgage detail of clients


Null Option Type








HOFirstTime CHAR(3) TEXT(3) YESNO NOT NULL First time home owner (YES/NO)

HOPropertyType CHAR(20) TEXT(20) PROPERTYTYPE NOT NULL Type of home to be purchased

HOInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULL Amount to be paid back on each instalment date

HOValue NUMBER(15,4) CURRENCY AMOUNT NULL Value in euros lent to the client for the home owner mortgage

HOInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

Type of instalment option the client chooses

HOPayType CHAR(18) TEXT(18) PAYTYPE NOT NULL

Type of payment option the client chooses

HOAddress VARCHAR2(255) TEXT(255) ADDRESS NOT NULL

Address of the property which the home owner mortgage is based

HOCityTown VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

City or own which the property is located for the home owner mortgage

HOCounty VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

County which the property is located for the home owner mortgage

HOProvince VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

Province which the property is located for the home owner mortgage

HOCountry VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

Country which the property is located for the home owner mortgage.

HOTenure INTEGER INTEGER TENURE NOT Time period of the client's home

17

NULL owner mortgage.

HOPaymentType CHAR(18) TEXT(18) PAYTYPE NOT NULL

Type of payment for which the client chooses to pay back their home owner mortgage.

HOGuarantors VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

Individual(s) who have guaranteed the client's home owner mortgage.

HOPropertyDescription CLOB MEMO PURPOSE NOT NULL

A description of the client's intended property for the home owner mortgage.

Entity Name : GDHomeOwnerMortgageTransEntity Definition : Data regarding home owner mortgage payment and non-payment by clients


Null Option Type


HOTID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the home owner mortgage transaction table, i.e. its unique identifier.

HOCr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of instalment for which the client did not pay on the instalment date for their Home owner mortgage.

HODr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of instalment for which the client paid on the instalment date for their Home owner mortgage

HODate DATE DATETIME DATETIME NULL

The date for which the payment or non-payment took place for the client's home owner mortgage payments







Entity Name : GDPersonalInsuranceDetail

18

Entity Definition : Data regarding personal insurance detail of clients


Null Option Type








PIValue NUMBER(15,4) CURRENCY AMOUNT NULL The value in euros of the client's personal insurance contract.

PIPurpose CLOB MEMO PURPOSE NOT NULL

The purpose of the client taking out personal insurance.

PITenure INTEGER INTEGER TENURE NOT NULL

The Time Period of the client's insurance contract.

PIInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULLThe amount in euros that the client must pay on the instalment date for their personal insurance.

PIPaymentType CHAR(18) TEXT(18) PAYTYPE NOT NULL

The type of payment the client wishes to utilise in order to pay for their personal insurance.

PIRenewalDate DATE DATETIME DATETIME NULL The date of renewal for the client's personal insurance

PIInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

The type of instalment the client wishes to use for their personal insurance.

Entity Name : GDPersonalInsuranceTransEntity Definition : Data regarding personal insurance payment and non-payment by clients


Null Option Type


PITID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the personal insurance transaction table, i.e. its unique identifier.

PIDr NUMBER(15,4) CURRENCY AMOUNT NULL The amount of instalment which the client paid on the instalment

19

date for their personal Insurance.

PICr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of instalment which the client did not pay on the instalment date for their personal Insurance.

PIDate DATE DATETIME DATETIME NULLThe date for which the payment or non-payment took place for the client's personal insurance.







Entity Name : GDPersonalLoanDetailEntity Definition : Data regarding personal loan detail of clients


Null Option Type








PLValue NUMBER(15,4) CURRENCY AMOUNT NULL The value in euros that the client has taken out the personal loan for

PLGuarantors VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL

Individual(s) who have guaranteed the client's personal loan

PLInstalmentType CHAR(18) TEXT(18) INSTALMENTTYPE NOT NULL

The type of instalment the client wishes to utilise.

PLInstalmentAmount NUMBER(15,4) CURRENCY AMOUNT NULL The amount in euros that the client must pay on the instalment date.

PLPurpose CLOB MEMO PURPOSE NOT NULL

The client's purpose for taking out a personal loan

PLPaymentType CHAR(18) TEXT(18) PAYTYPE NOT NULL

The type of payment the client wishes to utilise to pay back the

20

personal loan.

PLTenure INTEGER INTEGER TENURE NOT NULL

The time period of the personal loan for the client.

Entity Name : GDPersonalLoanTransEntity Definition : Data regarding personal loan payment and non-payment by clients


Null Option Type


PLTID VARCHAR2(20) TEXT(20) ID NOT NULL

Primary key of the personal loan transaction table, i.e. its unique identifier

PLDr NUMBER(15,4) CURRENCY AMOUNT NULLThe amount of instalment which the client paid on the instalment date for the their personal loan

PLCr NUMBER(15,4) CURRENCY AMOUNT NULL

The amount of instalment which the client did not pay on the instalment date for the their personal loan

PLDate DATE DATETIME DATETIME NULLThe date for which the payment or non-payment took place for the client's personal loan







Entity Name : GDProductListEntity Definition : Stores the product ID and product name of a particular product


Null Option Type




PLProductName VARCHAR2(100) TEXT(100) GENERALNOTNULL NOT NULL Name of the financial product.

Table 1 Physical Dictionary

21

5.0 Primary and Foreign Key DictionaryThe following table will outline each primary and foreign key in the entities of the banking data

mining system. The table will specify the attribute, type of key and the primary key type in each of the

entities. No changes have been made to the primary and foreign key dictionary.

Entity Name : GDAutoInsuranceDetail

Attribute Name Key Type Primary Key Type

CPID FKConcatenated Primary KeyClientID FK

PLID FKEntity Name : GDAutoInsuranceTrans


AITID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDAutoLoanDetail



PLID FKEntity Name : GDAutoLoanTrans


ALTID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDBuyToLetmortgageDetail



PLID FKEntity Name : GDBuyToLetmortgageTrans


BTLTID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDClientDetail


ClientID PK Atomic Primary Key

23

Entity Name : GDClientProducts


PLID PK Atomic Primary Key

Entity Name : GDDepositAccountDetail



PLID FKEntity Name : GDDepositAccountTrans


DATID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDEducationalLoanDetail



PLID FKEntity Name : GDEducationalLoanTrans


ELTID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDHealthInsuranceDetail



PLID FKEntity Name : GDHealthInsuranceTrans


HITID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDHomeOwnerMortgageDetail



PLID FKEntity Name : GDHomeOwnerMortgageTrans


24

HOTID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDPersonalInsuranceDetail



PLID FKEntity Name : GDPersonalInsuranceTrans


PITID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDPersonalLoanDetail



PLID FKEntity Name : GDPersonalLoanTrans


PLTID PKConcatenated Primary KeyCPID FK

ClientID FKPLID FKEntity Name : GDProductList


PLID PK Atomic Primary Key

Table 2 Primary and Foreign Key Dictionary

25

6.0 Domain DictionaryThe following domains incorporated check constraints as well as datatype and character restrictions to limit the potential for faulty, inconsistent

or wrong data being entered into the respective field. An employer address domain has been added with a null option and a smaller character

restriction size of 100 compared to 255 of the address domain. The change was prompted due to an error in Microsoft access stating the datatype

of 255 was too large for the field, although the other addresses of 255 have been entered successfully. The datatype of VARCHAR2 for Oracle

and TEXT for access remains the same.

Domain Dictionary

Domain Constraint Type

Min Max Rule

Valid Values

Null Option Type

Oracle Data type

Access Data Type Description

Amount MinMax >=0 N/A NULL NUMBER(15,4) CURRENCYEntry must be greater or equal to 0

DepositAccCategory Valid Values N/A Savings, Current

NOT NULL CHAR(12) TEXT(12)

Entry can only contain the valid values

DepositAccType Valid Values N/AJoint, Student, Single



Education Valid Values N/A1st Level, 2nd Level, 3rd Level

NULL VARCHAR2(10) TEXT(10)Entry can only contain the valid values

InstalmentType Valid Values N/A

Weekly, Daily, Monthly, 6 Months, Annually


entry can only contain the valid values

26

MaritalStatus Valid Values N/A

Single, Divorced, Married, Partnership, Civil Partnership, Other

NULL CHAR(20) TEXT(20)entry can only contain the valid values

PayType Valid Values N/A

Cash, Standing Order, Direct Debit



PropertyType Valid Values N/A

Apartment, House, Condo, Villa, Other



Tenure MinMax >=0, <=50 N/A NOT

NULL INTEGER INTEGER

Entry must be greater or equal to 0 but less or equal to 50

VehicleType Valid Values N/A

Car, Motor Bike, Mini Bus, Mini Van, Van, Mobile Home



YesNo Valid Values N/A Yes, No, N/A, ?



GeneralNotNull N/A N/A N/A NOT NULL VARCHAR2(100) TEXT(100)

Miscellaneous mandatory entry

GeneralNull N/A N/A N/A NULL VARCHAR2(100) TEXT(100)

Miscellaneous non- mandatory entry

DATETIME N/A N/A N/A NULL DATE DATETIME Appropriate

27

date format of entry

EMAIL N/A N/A N/A NULL VARCHAR2(100) TEXT(100)

Null and datatype character restriction for email entries

ID N/A N/A N/A NOT NULL VARCHAR2(20) TEXT(20)

Not null and datatype character restriction for primary and foreign keys

NUMBER N/A N/A N/A NULL INTEGER INTEGER

Null and datatype identity for number entries

PHONE N/A N/A N/A NULL LONG LONG

Null and datatype identity for phone number entries

PURPOSE N/A N/A N/A NOT NULL CLOB MEMO

Not null large descriptive entries

VEHICLEREGNUMBER N/A N/A N/A NOT NULL VARCHAR2(50) TEXT(50)

Not Null and datatype restrictions for vehicle registration entries

ADDRESS N/A N/A N/A NOT NULL VARCHAR2(255) TEXT(255)

Not Null and datatype restrictions for address entries

28

EMPLOYERADDRESS N/A N/A N/A NULL VARCHAR2(100) TEXT(100)

Null and datatype restrictions for employer address entries

GENDER Valid Values N/A

Male, Female, Both, Other, Trans

NULL CHAR(18) CHAR(18)

Entry can be null but must if not must contain one of the valid values

Table 3 Domain Dictionary

29

7.0 Alterations and Modifications Logical Data Model In light of the LDM presentation and feedback session which took place on the 16th of

November 2015, a number of alterations and modifications where made to the proposed. An

analysis by the project team of the LDM model has also contributed further modifications to

the model. These alterations are as follows:

For attributes using the purpose domain the datatype was changed from VARCHAR

(255) to CLOB for Oracle and MEMO for access.

Attributes using DECIMAL(15,4) have been changed to NUMBER(15,4) for Oracle

in order to ensure the appropriate capture of currency information thus having the

relevant figures in the correct position in regards to the decimal point.

A gender attribute was added to the model as the project team determined the attribute

to be a relevant data source to the model.

PI_Tenure has been altered to PITenure as the previous version violated database

rules in regards to no spaces between words in attributes. This would have caused

confusion during the testing stage and may have delayed the project if not corrected at

this point.

An “EmployerAddress” domain was added with a null option datatypes

VARCHAR2(100) and TEXT(100) as Access prompted a “Field too large” error

during DDL testing. Criteria from this domain were applied to the employer address

attribute in the client detail table.

Transaction tables have been renamed “trans” e.g. GDPersonalInsuranceTrans as

having as Oracle has a character limit on the table names.

Corrected minor spelling mistakes in the report and LDM.

8.0 DDL Code Test for Oracle and AccessA preliminary test was successfully conducted of the DDL code at the LDM stage for

Microsoft Access and Oracle RDBMS platforms. The preliminary test was supposed to be

included in the LDM but due to an upload malfunction the latest LDM version was not

submitted. The only difference between the two reports was the preliminary tests. One issue

arose on the preliminary test of the Oracle platform which occurred in the

GDHomeOwnerMortgageTrans and GDBuyToLetMortgageTrans tables. Their foreign key

constraint names R-7 (GDHomeOwnerMortgageTrans) and R_6

30

(GDBuyToLetMortgageTrans) are in use by another database on the project team’s account

thus these constraint names could not be used. As a result R_7 was adjusted to R_77 and R_6

to R_67.

Figure 1 Oracle Foreign Key Error

Microsoft Access was unable to take the check constraints contested in Oracle; as a result

these constraints were removed from the Access DDL code and will need to be adjusted

manually in Access but this is out of scope for this project due to time constraints.

VARCHAR2 has been changed to TEXT, DATE has been altered to DATETIME and

NUMBER (15,4) adjusted to CURRENCY in order to facilitate the Access platform.

One small issue also arose with the preliminary test on the Microsoft Access platform with

regards to the length of the employer address on the client detail table. Access identified that

the datatype of TEXT (255) was too large for this attribute.

Figure 2 Access Employer Address Error

As a result a new domain in Erwin was created, the “EmployerAddress” which incorporated a

Null option and a VARCHAR2 (100) for the Oracle system. TEXT (100) has been utilised

31

for the Access system. With all of these changes made the Oracle DDL and Access DDL was

retested with the alterations in mind and ran successfully on both platforms.

A number of adjustments were suggested at the LDM feedback session on November 16 th

2015 such as using CLOB for Oracle and MEMO in Access for attributes with a large intake

of data. Using NUMBER (15,4) instead of DECIMAL (15,4) was also suggested at the

feedback session to ensure the numbers are correctly formatted on the appropriate side of the

decimal place when being entered into the system. The suggested changes were implemented

on the Erwin model then the code was forward engineered. Taking into account lessons

learned from the preliminary tests two DDL codes were manufactured, one altered for Oracle

and the other for Access. All DDL codes ran smoothly on both platforms indicating the

relationships between the tables have been realised.

Appendix A shows an Access ERD which shows how the relationships between the tables are

connected in the access system.

Appendix B identifies the describe statements that were run in Oracle to confirm successful

entry of the code into the Oracle system.

Appendix C incorporates an Access documenter report identifying the relationships between

the tables as well as the attribute types and sizes.

9.0 Oracle DML Query Test As Can be seen in Appendix D Test data has been entered into the client detail, product list

and personal insurance detail tables in order to give a quick indication as to whether or not

the proposed banking data mining system can meet the business case of manipulating,

grouping, classifying and clustering customer information. Thus having the ability to spot

trends and further sell existing and new finincial products to clients.

The three queries and results below demontrate the model has been erected to a functional

state and is of a quality and standard to undergo futher testing. The results of the query were

pre-planned in order to test if the query was correct in terms of construction and output.

32

9.1 Test DML Query 1The first query was utilised to check that all of the product IDs and product names have been

entered successfully in the product list table. Nine products separate products should have

been returned which was the case as seen below.

9.2 Test DML Query 2The second test query has been created to identify all active clients and their active products.

The results should come back with some clients e.g. Casey and Richard having only a

deposit account and the rest having a depsoit account and personal insurance. The query was

successful as demonstrated by the results below where Casey and Richard only having a

deposit account where the others have both a depsoit account and personal insurance.

33

9.3 Test DML Query 3The final test query was designed to test that information could be withdrawn from multiple

tables and filtered based on a number of criteria. The query is supposed to return the names,

tenure, payment type and value of each of the client’s personal insurance with a value greater

than or equal to 10,000. Only two records should be returned which can be seen below. This

proves that the hierarchal structure of the database allows an end user to dive in deeper on

certain aspects of a particular product in order to spot trends or generate raw data to be

utilised in other data analysis software packages.

All three queries ran successfully during the preliminary DML tests thus the model is

competent enough to move forth to a more comprehensive testing process before becoming a

live system.

34

10.0 Entity Relationship DiagramThe first diagram shows the original model proposed at CDM level, the second diagram

shows the proposed model at LDM level and the third shows the model at PDM level

including the recommendations and modifications to the model as suggested at the feeback

sesson on the 16th of November 2015.

DDL script for the banking data ming system has been tested successfully on both Mircosoft

Access and Oracle relational database management systems (RDBMS).

35

Figure 3 Banking Data Mining System at CDM Level

35

36

Figure 4 Banking Data Mining System at LDM Level

Figure 5 Banking Data Mining System at PDM Level

37

11.0 ConclusionThe purpose of this report is to provide a detailed synopsis of the banking data mining system

proposed in the business case. Alterations have been made to the model at all levels from the

conceptual to the physical level in order to ensure the system has been erected in the most

efficient way to allow the end user to query the system with relative ease.

Due to the hierarchal structure of the database as well as the addition of the product list and

client product table at LDM level will allow for changes within the model such as adding and

deleting product and transaction tables with relative ease as they all follow the same pattern.

End user querying is also made easy by the database rule of having all attributes with the

exception of the client detail table to have an abbreviation of their parent table to minimise

confusion when selecting similar attributes in queries. Also the logical sequence of the model

allows end users to decipher where the relevant data is and the logic of join queries such as

INNER JOINS are made relatively easy due to the hierarchal structure. This makes the

clustering, classification and grouping of clients relatively simple.

Due to the relatively straight forward hierarchal structure, it should be relatively easy to

develop interface queries which will help in generating the face of the database. This will

enable the facilitation of information collection from a variety of sources from mobile

applications, online banking or traditional methods such as manual entry. This flexibility

ensures the bank is able to capture data from a variety of sources and quickly add new

collection sources to the model.

With the DDL code running successfully on both systems and no issues arising the model

such exit the physical level and move into the interface creation stage if applicable and then

strenuous testing by end users.

Successful preliminary testing of utilising DML code on test data suggests the model is of a

quality and standard to move forward onto more strenuous testing in order to ensure its

functionality and relevancy to the business case.

38

Appendix-A Access DDL ERD

Appendix-B Oracle DDL Describe Statements

Appendix-C Access DDL Documenter Report E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDAutoInsuranceDetail Page: 1

PropertiesDateCreated: 23/11/2015 21:38:18 LastUpdated: 23/11/2015 21:44:16RecordCount: 0 Updatable: True

ColumnsName Type SizeAIValue Currency 8AIVehicleType Short Text 18AILicenceNO Short Text 50AIVehicleFinance Short Text 100AITenure Long Integer 4AIInstalmentAmount Currency 8AIInstalmentType Short Text 18AIPaymentType Short Text 18AIRenewalDate Date With Time 8AIVehicleModel Long Text -CPID Short Text 20ClientID Short Text 20PLID Short Text 20AIFullLicence Short Text 3

Relationships

GDAutoInsuranceDetailGDAutoInsuranceTrans

GDAutoInsuranceDetail GDAutoInsuranceTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID

Attributes: EnforcedRelationshipType: One-To-Many

GDClientProductsGDAutoInsuranceDetail

GDClientProducts GDAutoInsuranceDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID

Attributes: EnforcedRelationshipType: One-To-One

E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDAutoInsuranceTrans Page: 2


ColumnsName Type SizeAIDr Currency 8AICr Currency 8AIDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20AITID Short Text 20

Relationships

GDAutoInsuranceDetailGDAutoInsuranceTrans

GDAutoInsuranceDetail GDAutoInsuranceTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDAutoLoanDetail Page: 3


ColumnsName Type SizeALValue Currency 8ALVehicleType Short Text 18ALVehicleModel Short Text 100ALRegistrationNumber Short Text 50ALGarantors Short Text 100ALInstalmentType Short Text 18AlInstalmentAmount Currency 8ALTenure Long Integer 4CPID Short Text 20ClientID Short Text 20PLID Short Text 20ALInsurance Short Text 3ALFullLicence Short Text 3

Relationships

GDAutoLoanDetailGDAutoLoanTrans

GDAutoLoanDetail GDAutoLoanTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


GDClientProductsGDAutoLoanDetail

GDClientProducts GDAutoLoanDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDAutoLoanTrans Page: 4


ColumnsName Type SizeALDr Currency 8ALCr Currency 8ALDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20ALTID Short Text 20

Relationships

GDAutoLoanDetailGDAutoLoanTrans

GDAutoLoanDetail GDAutoLoanTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDBuyToLetMortgageDetail Page: 5


ColumnsName Type SizeBTLPropertyType Short Text 20BTLValue Currency 8BTLInstalmentType Short Text 18BTLPayType Short Text 18BTLAddress Short Text 255BTLCityTown Short Text 100BTLCounty Short Text 100BTLProvince Short Text 255BTLCountry Short Text 100BTLIInstalmentAmount Currency 8BTLTenure Long Integer 4BTLPaymentType Short Text 18BTLGuarantors Short Text 100BTLPropertyDescription Long Text -CPID Short Text 20ClientID Short Text 20PLID Short Text 20BTLFirstTime Short Text 3

Relationships

GDClientProductsGDBuyToLetMortgageDetail

GDClientProducts GDBuyToLetMortgageDClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDBuyToLetMortgageDetail Page: 6

GDBuyToLetMortgageDetailGDBuyToLetMortgageTrans

GDBuyToLetMortgageD GDBuyToLetMortgageTrCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDBuyToLetMortgageTrans Page: 7


ColumnsName Type SizeBTLCr Currency 8BTLDr Currency 8BTLDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20BTLTID Short Text 20

Relationships

GDBuyToLetMortgageDetailGDBuyToLetMortgageTrans

GDBuyToLetMortgageD GDBuyToLetMortgageTrCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDClientDetail Page: 8


ColumnsName Type SizeClientID Short Text 20Forename Short Text 100Gender Short Text 18Surname Short Text 100DOB Date With Time 8Address Short Text 255CityTown Short Text 100County Short Text 100Province Short Text 100Country Short Text 100HomePhone Long Integer 4WorkPhone Long Integer 4Mobile Long Integer 4Email Short Text 100Profession Short Text 100Employer Short Text 100EmployerAddress Short Text 100AnnualSalary Currency 8MaritalStatus Short Text 20Ethnicity Short Text 100ReligiousAffiliation Short Text 100MaleChildren Long Integer 4FemaleChildren Long Integer 4InfoUseOptIn Short Text 3ClientActive Short Text 3

Relationships

GDClientDetailGDClientProducts

GDClientDetail GDClientProductsClientID 1 ClientID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDClientProducts Page: 9


ColumnsName Type SizeClientID Short Text 20PLID Short Text 20CPID Short Text 20CPActive Short Text 3

Relationships

GDClientDetailGDClientProducts

GDClientDetail GDClientProductsClientID 1 ClientID


GDProductListGDClientProducts

GDProductList GDClientProductsPLID 1 PLID


GDClientProductsGDPersonalLoanDetail

GDClientProducts GDPersonalLoanDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID



GDClientProductsGDDepositAccountDetail

GDClientProducts GDDepositAccountDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


GDClientProductsGDHealthInsuranceDetail

GDClientProducts GDHealthInsuranceDetaClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


GDClientProductsGDBuyToLetMortgageDetail

GDClientProducts GDBuyToLetMortgageDClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


GDClientProductsGDHomeOwnerMortgageDetail

GDClientProducts GDHomeOwnerMortgagClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID



GDClientProductsGDAutoLoanDetail

GDClientProducts GDAutoLoanDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


GDClientProductsGDAutoInsuranceDetail

GDClientProducts GDAutoInsuranceDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


GDClientProductsGDEducationalLoanDetail

GDClientProducts GDEducationalLoanDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


GDClientProductsGDPersonalInsuranceDetail

GDClientProducts GDPersonalInsuranceDeClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDDepositAccountDetail Page: 12


ColumnsName Type SizeGADAccType Short Text 18GADCategory Short Text 12CPID Short Text 20ClientID Short Text 20PLID Short Text 20

Relationships

GDDepositAccountDetailGDDepositAccountTrans

GDDepositAccountDetail GDDepositAccountTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


GDClientProductsGDDepositAccountDetail

GDClientProducts GDDepositAccountDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDDepositAccountTrans Page: 13


ColumnsName Type SizeGADTDate Date With Time 8GADTNarration Long Text -GADTDeposits Currency 8GADTWithdrawals Currency 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20DATID Short Text 20

Relationships

GDDepositAccountDetailGDDepositAccountTrans

GDDepositAccountDetail GDDepositAccountTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDEducationalLoanDetail Page: 14


ColumnsName Type SizeELValue Currency 8ELEducationType Short Text 10ELSchoolAddress Short Text 255ELSchoolCityTown Short Text 100ELSchoolCounty Short Text 100ELSchoolProvince Short Text 100ELSchoolCountry Short Text 100ELPreviousEducation Short Text 10ELInstalmentType Short Text 18ELInstalmentAmount Currency 8ELPaymentType Short Text 18ELTenure Long Integer 4ELGuarantors Short Text 100CPID Short Text 20ClientID Short Text 20PLID Short Text 20ELLivingAtHome Short Text 3

Relationships

GDEducationalLoanDetailGDEducationalLoanTrans

GDEducationalLoanDetail GDEducationalLoanTranCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDEducationalLoanDetail Page: 15

GDClientProductsGDEducationalLoanDetail

GDClientProducts GDEducationalLoanDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDEducationalLoanTrans Page: 16


ColumnsName Type SizeELDr Currency 8ELCr Currency 8ELDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20ELTID Short Text 20

Relationships

GDEducationalLoanDetailGDEducationalLoanTrans

GDEducationalLoanDetail GDEducationalLoanTranCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDHealthInsuranceDetail Page: 17


ColumnsName Type SizeHIValue Currency 8HITenure Long Integer 4HIInstalmentAmount Currency 8HIInstalmentType Short Text 18HIPaymentType Short Text 18HIRenewalDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20HIMedicalReport Short Text 3

Relationships

GDHealthInsuranceDetailGDHealthInsuranceTrans

GDHealthInsuranceDeta GDHealthInsuranceTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


GDClientProductsGDHealthInsuranceDetail

GDClientProducts GDHealthInsuranceDetaClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDHealthInsuranceTrans Page: 18


ColumnsName Type SizeHIDr Currency 8HICr Currency 8HIDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20HITID Short Text 20

Relationships

GDHealthInsuranceDetailGDHealthInsuranceTrans

GDHealthInsuranceDeta GDHealthInsuranceTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDHomeOwnerMortgageDetail Page: 19


ColumnsName Type SizeHOPropertyType Short Text 20HOValue Currency 8HOInstalmentType Short Text 18HOPayType Short Text 18HOAddress Short Text 255HOCityTown Short Text 100HOCounty Short Text 100HOProvince Short Text 100HOCountry Short Text 100HOInstalmentAmount Currency 8HOTenure Long Integer 4HOPaymentType Short Text 18HOGuarantors Short Text 100HOPropertyDescription Long Text -CPID Short Text 20ClientID Short Text 20PLID Short Text 20HOFirstTime Short Text 3

Relationships

GDClientProductsGDHomeOwnerMortgageDetail

GDClientProducts GDHomeOwnerMortgagClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDHomeOwnerMortgageDetail Page: 20

GDHomeOwnerMortgageDetailGDHomeOwnerMortgageTrans

GDHomeOwnerMortgag GDHomeOwnerMortgagCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDHomeOwnerMortgageTrans Page: 21


ColumnsName Type SizeHOCr Currency 8HODr Currency 8HODate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20HOTID Short Text 20

Relationships

GDHomeOwnerMortgageDetailGDHomeOwnerMortgageTrans

GDHomeOwnerMortgag GDHomeOwnerMortgagCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDPersonalInsuranceDetail Page: 22


ColumnsName Type SizePIValue Currency 8PIPurpose Long Text -PITenure Long Integer 4PIInstalmentAmount Currency 8PIPaymentType Short Text 18PIRenewalDate Date With Time 8PIInstalmentType Short Text 18CPID Short Text 20ClientID Short Text 20PLID Short Text 20

Relationships

GDPersonalInsuranceDetailGDPersonalInsuranceTrans

GDPersonalInsuranceDe GDPersonalInsuranceTrCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


GDClientProductsGDPersonalInsuranceDetail

GDClientProducts GDPersonalInsuranceDeClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDPersonalInsuranceTrans Page: 23


ColumnsName Type SizePIDr Currency 8PICr Currency 8PIDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20PITID Short Text 20

Relationships

GDPersonalInsuranceDetailGDPersonalInsuranceTrans

GDPersonalInsuranceDe GDPersonalInsuranceTrCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDPersonalLoanDetail Page: 24


ColumnsName Type SizePLValue Currency 8PLGuarantors Short Text 100PLInstalmentType Short Text 18PLInstalmentAmount Currency 8PLPurpose Long Text -PLPaymentType Short Text 18PLTenure Long Integer 4CPID Short Text 20ClientID Short Text 20PLID Short Text 20

Relationships

GDPersonalLoanDetailGDPersonalLoanTrans

GDPersonalLoanDetail GDPersonalLoanTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


GDClientProductsGDPersonalLoanDetail

GDClientProducts GDPersonalLoanDetailClientID 1 1 ClientIDPLID 1 1 PLIDCPID 1 1 CPID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDPersonalLoanTrans Page: 25


ColumnsName Type SizePLDr Currency 8PLCr Currency 8PLDate Date With Time 8CPID Short Text 20ClientID Short Text 20PLID Short Text 20PLTID Short Text 20

Relationships

GDPersonalLoanDetailGDPersonalLoanTrans

GDPersonalLoanDetail GDPersonalLoanTransCPID 1 CPIDClientID 1 ClientIDPLID 1 PLID


E:\GFIS\Semester 9\Data Modelling & Analysis\Group 23 November 2015Project\PDM\D_PDM_Bank_Data_Mining_System.accdbTable: GDProductList Page: 26


ColumnsName Type SizePLID Short Text 20PLProductName Short Text 100

Relationships

GDProductListGDClientProducts

GDProductList GDClientProductsPLID 1 PLID


Appendix D Test Data for DML Query TestINSERT INTO GDClientDetail VALUES( 'C1','Lee', 'Ward','Male', '02-Dec-1992', '3 Ferndale RD', 'Waterford', 'Waterford','Munster', 'Ireland', 051345881, 0863165544, 0893165544, '[email protected]', 'business analyst', 'Johnson and Johnson', 'IDA Waterford', 80000,'Single', 'Irish', 'Christian', 0, 0, 'Yes', 'Yes');INSERT INTO GDClientDetail VALUES( 'C2','Leon', 'Beasley','Male', '13-Feb-1990', '6 Johns RD', 'Waterford', 'Waterford','Munster', 'Ireland', 051345341, 0870065534, 0893715543, '[email protected]', 'software developer', 'Bausch and Lomb', 'IDA Waterford', 90000,'Married', 'Irish', 'Christian', 2, 1, 'Yes', 'Yes');INSERT INTO GDClientDetail VALUES( 'C3','Joseph', 'Greene','Male', '22-Apr-1988', '13 Patricks St', 'Waterford', 'Waterford','Munster', 'Ireland', 051345621, 0873155541, 0890030544, '[email protected]', 'data analyst', 'Eishtec', 'IDA Waterford', 60000,'Single', 'Irish', 'Christian', 0, 1, 'Yes', 'Yes');INSERT INTO GDClientDetail VALUES( 'C4','Casey', 'Mangan','Male', '27-Mar-1994', '5 Ashley Court RD', 'Waterford', 'Waterford','Munster', 'Ireland', 051006241, 0853195533, 0893165544, '[email protected]', 'fund manager', 'Teva', 'IDA Waterford', 100000,'Married', 'Irish', 'Christian', 0, 3, 'Yes', 'Yes');INSERT INTO GDClientDetail VALUES( 'C5','Richard', 'Byrne','Male', '02-Jan-1987', '33 Ferndale Ave', 'Waterford', 'Waterford','Munster', 'Ireland', 051346781, 0863100044, 0893335534, '[email protected]', 'IT infrastruture engineer', 'Honeywell', 'IDA Waterford', 65000,'Single', 'Irish', 'Christian', 0, 0, 'Yes', 'Yes');

INSERT INTO GDProductList VALUES ('HOM1', 'Home Owner Mortgage');INSERT INTO GDProductList VALUES ('BTLM1', 'Buy to Let Mortgage Mortgage');INSERT INTO GDProductList VALUES ('PL1', 'Personal Loan');INSERT INTO GDProductList VALUES ('AL1', 'Auto Loan');INSERT INTO GDProductList VALUES ('EL1', 'Educational Loan');INSERT INTO GDProductList VALUES ('PI1', 'Personal Insurance');INSERT INTO GDProductList VALUES ('HI1', 'Health Insurance');INSERT INTO GDProductList VALUES ('AI1', 'Auto Insurance');INSERT INTO GDProductList VALUES ('DA1', 'Depsoit Account');

INSERT INTO GDClientProducts VALUES ('C1', 'DA1', 'P1', 'Yes');INSERT INTO GDClientProducts VALUES ('C2', 'DA1', 'P1', 'Yes');INSERT INTO GDClientProducts VALUES ('C3', 'DA1', 'P1', 'Yes');INSERT INTO GDClientProducts VALUES ('C4', 'DA1', 'P1', 'Yes');INSERT INTO GDClientProducts VALUES ('C5', 'DA1', 'P1', 'Yes');

INSERT INTO GDClientProducts VALUES ('C1', 'PI1', 'P1', 'Yes');INSERT INTO GDClientProducts VALUES ('C2', 'PI1', 'P1', 'Yes');INSERT INTO GDClientProducts VALUES ('C3', 'PI1', 'P1', 'Yes');

INSERT INTO GDPersonalInsuranceDetail VALUES (10000, 'insure cat', 5, 100, 'Standing Order', '10-Jan-2016', 'Weekly', 'P1', 'C1', 'PI1');INSERT INTO GDPersonalInsuranceDetail VALUES (5000, 'insure dog', 1, 50, 'Cash', '12-Dec-2015', 'Weekly', 'P1', 'C2', 'PI1');INSERT INTO GDPersonalInsuranceDetail VALUES (20000, 'insure tv', 1, 500, 'Cash', '10-Jan-2017', 'Weekly', 'P1', 'C3', 'PI1');

Appendix E Meeting Minutes

MINUTES OF MEETING

GROUP D. Members

Lee ROCKKC SHARATH

Johnny SYLLIASRichard Olayele AWOSIKA

GFIS 2015/2016 Session

Date: Friday, 25 th September 2015

In attendance:

1. Lee Rock - Project Leader2. Richard Olayele Awosika - Secretary3. Johnny Syllias4. K. C. Sharath

Venue: AT 126

Time: 2:24pm

Business Case: A DATABASE MODEL TO ENABLE CAPTURE, CLASSIFICATION AND CLUSTERING OF CUSTOMERS FOR TARGETED MARKETING OF SPECIFIC FINANCIAL PRODUCTS / SERVICES.

It was resolved on Tuesday the 22nd of September 2015 at an impromptu meeting that members should research in different financial products that Banks could offer. The group also resolved that a derivative innovative product be introduced which requires an organization e.g. a Bank introduce products and services of its customers to other clients within the same database and thus derive income from such.

A further illustration of this innovative product can be likened to a first time mortgagor (the customer who has just bought a mortgage) being offered services and products like house furniture, kitchen equipment’s by the Mortgagee (the Bank) because the Furniture company and the Kitchen equipment company are also customers of the Bank. This way the Bank has not only sold mortgage to the mortgagor but also offered other complementary products to existing customers (within the same database) thus deriving income from every offer accepted and closed. So this is an added value to the Mortgagor and to the Vendor who are all customers of the Bank.

At the resumed sitting of this meeting on Friday the 25th September 2015, members had researched into different financial products which includes but not limited to Mortgages, Loans, Insurances, Deposits and Credit Cards with each of these products having subsets. For example Loans was further divided into Car Loans, House Improvement Loans, First Job Loans, Education Loans, Wedding Loans, and Travel Loans etc.

Financial ProductsWe concentrated deeply on Mortgages having identified some of the products under Mortgages as First Time Buyers, Home Movers, Buy To Let and Top up Mortgages.

We initially resolved that Mortgages should be the only product with the Personal details being a trigger for introducing other products. After several discussions it was resolved that we should widen the financial products offered but limit those products to:

Mortgages (with subsets like First Time Buyers, Home Movers, Buy to Let); Top Up Mortgage (a different product on its own) Loans (divided into Auto, Personal and Educational); Insurance (divided into Mortgage, Health, Car and Loan)

It was agreed that for Car Loans it should be renamed Auto and not Car because customers obtain loans for other automated machines apart from Cars, even though Ireland hardly uses tricycles.

Facebook and WhatsApp Account Created:The group also agreed after much deliberation on the financial products that a Facebook account be created which was created immediately.

On Facebook the group is called Data Modeling GFIS 2015.On WhatsApp the group is called Data Modeling Group D.

Date and Time of MeetingsIt was also agreed that the group meet on Thursdays, 10am – 12pm at the Applied Technology Building, 126 (AT126).

Information Dissemination and the Data Protection ActThis issue came up with reference to the fact that the Banks (who will be marketing financial products) to other customers as a way of alternative income may be hampered by the Data Protection Act. The question for determination would be;

1. Whether the Bank has the right to introduce Vendors (e.g. Tesco) to mortgagors who just bought a mortgage?

2. Or should the Bank be introducing the mortgagors to Tesco? Taking into consideration the Data Protection Act.

One of the members who had worked in the Bank informed us that this is feasible in other countries like India because Banks buy data from agencies and use the data to further their business.

In summary, on the part of introducing the products to the mortgagors who are also customers of the Banks, there is no law forbidding that because they are customers of the Bank and all the Bank is doing is to further add value by pointing them to vendors who will give them value.

But on the part of selling the mortgagors information to vendors like Tesco, the Data Protection Act may forbid this and until this is looked into, we may not be able to harness the full potentials of these innovative concept. However, it was resolved that if this is a problem, the model can be launched in another country.

The meeting was adjourned to 10am on Thursday the 1st of October 2015

Deliverables

Lee Rock – To work on the Mortgage Entity and Client Entity, its attributes and the transaction table on Erwin

Richard – To work on the Loans Entity with subsets restricted to Auto, Personal and Educational subsets, its attributes and the transaction table on Erwin

KC – To work on the Insurance Entity with subsets restricted to Loan, Car, Health and Mortgage Insurance, its attributes and the transaction table on Erwin

Johnny – To work on a client expenditure account and the attributes of a client expenditure account will be and all necessary details in a client account.

Meeting ended at 5.13pm

Date: Thursday, 1 st October 2015

In attendance:

5. Lee Rock - Project Leader6. Richard Olayele Awosika - Secretary7. Johnny Syllias8. K. C. Sharath

Venue: AT 126

Time: 10:48am

The meeting started with all members in attendance and the under listed issues were discussed

1. Adoption of Minutes of Last Meeting

a. The Minutes of last meeting was uploaded on the group Facebook page by Richard. It was downloaded and all agreed that the contents represented the deliberations of the meeting of the 25th September 2015 except for some minor correction of Client Detail Account to Client Expenditure Account which was the responsibility of Johnny as agreed at the last meeting.

2. Deliverables from Last Meeting

a. Lee: Lee had worked on the Mortgage sector with subsets like Buy to Let and Home Owner entities which were created with all the attributes on ERWIN. The transaction tables and the Client Detail entity with all the attributes had also been done.

b. Richard: The loan sector had been researched and all the subsets of the loan sector as agreed at the last meeting namely – Auto Loan, Educational Loan and Personal Loan which had also been created on ERWIN. The entities in each sector was agreed by all.

c. Sharath: Had also researched on Insurance with all the subsets namely Car Insurance, Health Insurance, Mortgage Insurance and Loan Insurance which was created on ERWIN and uploaded. All the entities were agreed and uploaded.

d. Johnny: Had researched on the client expenditure account and its attributes as agreed at the last meeting which was uploaded to ERWIN on same day.

3. Issues on ERWIN

a. Entity Relationships: Issues on ERWIN such as the relationships were discussed and agreed by all parties. The transaction tables were also created and issues as regards the functionality of some attributes were resolved. It was also agreed that only functional details should be inserted instead of having a database with so much detail that is not functional.

b. Domains: Certain domains such as the Yes/No domains for first time buyers, Date Domains, Marital Status Domains and the Education domains were agreed to be created.

c. Lee made efforts to see Dr. Aidan for his opinion on how far we have gone having developed the concept and modeled the relationships of the entities but unfortunately he was unable to locate him.

4. CDM REPORT

a. The report was started today having agreed that time is short and the need to start working on the CDM report was agreed. A template was obtained from Moodle to guide us. The details of the CDM report were agreed and the contents of the CDM report was agreed to be shared between members to develop and ensure its uploaded on the Facebook page before the next meeting.

b. Lee was able to collate some of the appendices and definition of terms on that day which was uploaded on word by Richard while Sharath and Johnny worked on entity relationships and CDM report respectively.

5. DELIVERABLES

a. Johnny:i. To work on the CDM report with special emphasis on

1. Introduction and2. Strategy employed

b. Sharath: i. To work on the Business Case section of the CDM report

ii. To look at the entities and attributes for consistency purposesiii. To also work with Richard on the review and analysis section of the

report

c. Lee: i. To work on the cardinality and optionality of the relationships

ii. To do the domains iii. To endeavor to see Dr. Aidan

d. Richard:

i. To get the minutes of the meeting done like the last one and upload before the next meeting.

ii. To work on the review and analysis section of the report iii. To work on the conclusion of the report

The meeting was adjourned to Monday, 5th of October 2015 after the Data Modeling Class

Meeting ended at 2pm

Date; Thursday, 23rd October 2015Time; 14.40Venue; AT 121

Group D Members

K. C. Sharath Project Leader Johnny Syllias Secretary Lee Rock Richard Olayele Awosika

The meeting started with all members in attendance on time at about 14.40 pm and the following listed issues were discussed

Feedback and Lesson learnt from the CDM Design and Presentation.The meeting commenced with rotation of the roles and responsibilities of the group members. KC Sharath assumes the Group Project Leadership Role from Lee Rock. I, Johnny Syllias shoulder the position, Group Secretary from Richard Olayele Awosika. All new roles and responsibility begins with the effect from 23rd October 2013

CDM Presentation FeedbackThe main feedback from the CDM presentation was simplify our CDM and so what did is brain storming where each member put forward his perspective on how to achieve CDM modification. This was a bit challenge for us because initially we couldn’t seem to agree on one approach for the modification. Opportunity was given to all voiced out how his approach would enable us to achieve our CDM modification. After discussing the root of our CDM Issue, We all agreed that the best fit is to add two more tables.

Structure of Our LDM ProjectThe design and the structure of our LDM report were discussed. Each put forward his view and in the end we adopted one approach which believed that is the best way forward. • Richard Olayele Awosika volunteer to work on the introduction while Lee Rock and K. C. Sharath engaged in normalization and I Johnny Syllias taking notes for the meeting and LDM reports.

We treated our group meeting as formal but flexible to enable each member to take break as needed.

The meeting ended at about 18.30 with final word from K. C. Sharath, our LDM project leader who propose the next meeting to be on the 27 th October 2015, at 10.00 am where we all agreed

Date; Tuesday, 27th October 2015Time; 10.15Venue; AT 121

Progress Made to Date and what need to be doneThe meeting started with all members present on time at about 10.15 am with a short briefing from K. C. Sharath, our LDM project Manager about the progress made to date on the LDM project and what need to be done . Opportunities was given to all the members to voice their input on how the project should be advance to the next level and who is willing to do what to move it forward. Lees Rock accepted to develop a table for the primary foreign keys, while, Johnny Syllias, Richard Olayele Awosika and K. C. Sharath embarked on normalization. After successfully completed the day’s task we all agreed to call it a day at around 16.45 pmThe next meeting was schedule on the 4th of November 2015 at 10.00 to possibly complete the LDM project

Date: Tuesday, 18th November 2015

In attendance:

9. Johnny Syllias - Project Leader10. Richard Olayele Awosika - Project Secretary11. Lee Rock 12. K. C. Sharath

Venue: AT 126

Time: 10:13am

The meeting started with all members in attendance and the below mentioned were the topics of discussion.

6. Follow up from LDM session

a. The team did a successful presentation on 16th Nov. 2015 of the LDM model accommodating all the suggested changes and recommendations made during the first presentation on 19th Oct. 2015. After the in depth feedback from Aidan on the LDM model, the team has now forayed into the third phase i.e. Physical Data Modelling of the Project.

7. Deliverables from Last Meeting

a. Lee: Had the task of working on establishing the primary and foreign key dictionary as well as the logical dictionary. He checked the stability and flow of the LDM model and made alterations by bringing in new tables and attributes to simplify the Erwin model and ensured that the model had a hierarchy.

b. Johnny: He worked on developing the introductory session of the report and scrutinized the consistency of the attributes developed and made modifications with respect to the attribute definitions in the Erwin model.

c. Sharath: He was the project manager for the LDM phase. He completed the task of developing the Normalization part for the Erwin model and checked the redundancy and ensured the workability of the Erwin model by checking the logic of all the defined attributes.

d. Richard: He was the secretary for the CDM phase and tracked all the developments from the CDM to LDM and reflected the same in the form of minutes of the meeting. He shared the responsibility of checking the consistency of data types and definitions along with Richard.

8. Task Allocations and Action Plans

a. The discussion of the day started with the feedback received from Aidan on the LDM model. As per the feedback Lee has agreed to change the data type of the text from VARCHAR to MEMO in access.

b. The second alteration with respect to the feedback was on the data type to be used for indicating the monetary values. As per the recommendation from Aidan, the Data type Decimal was replaced with Number in SQL code.

c. Changes were made with regard to the inconsistencies in some of the entity table names that existed in Erwin Model by almost making sure that there exist zero error(s) as we cannot afford to have one at this phase of the project.

d. The team members individually took some time in going through the sample PDM file and thoroughly understood the requirements at this phase.

e. For the PDM stage Johnny was nominated as the Project Manager, Richard as Secretary, Sharath KC will be responsible for noting the minutes of the meeting and the decision was fully agreed upon by the team.

f. Since the primary and foreign key dictionary was one of the most impressive parts of LDM, Lee has decided to come up with a dictionary defining the

constraints as well as the index defining the abbreviations used throughout the project.

g. It has been agreed that the team members would divide and develop different chapters of the PDM report. Lee completed a portion of PDM introduction, Sharath has agreed to work on the alterations and modifications to be accommodated at the PDM phase, Richard and Johnny has taken up the creation of PDM and conclusion and completion of the same within the next meeting.

h. Although the SQL script and Access codes were partially developed, further fine tuning was to be done and a report of the model was generated in access which came up with remarks of the designed model.

i. The Access and Oracle codes has been shared within the Data Modelling Facebook group so that each member of the team can run these codes in SQL and access platform with dummy data and can further trial test the codes with further statements taught during the regular class hours.

The meeting was dissolved for the day and member decided to gather on Monday 25th

November 2015.

Meeting ended at 12.10pm

Date. 25 th November 2015

9. PDM Meeting, Group D

In attendance:

13. Johnny Syllias - Project Leader14. Richard Olayele Awosika - Project Secretary15. Lee Rock 16. K. C. Sharath

Venue: AT 126

Time: 10:13am

The meeting started with all members in attendance and the below mentioned were the topics of discussion.

a. In the last meeting of PDM phase on 18th Nov. 2015 the team has agreed upon certain deliverables and action plans. It was observed that all the tasks allocated to team members have been completed. Each team member uploaded their work on the private data modelling

group in Facebook. All the team members were aware that 95% of the work was done during the last meeting as well during the off days on an individual basis.

b. Each team member reviewed the different chapters of the report and came up with clarifications and doubts. For instance as per the established database rule GDAutoInsurance Transaction entity table is supposed to be named as GDAutoInsuranceTrans but it was found that even though this database ruled was captured in the report, similar change was not reflected in the headings of transaction tables in logical, primary and foreign key dictionaries.

c. In the Alterations and modification section of the report, in spite of including all the changes, the change in name of one of the attribute was not captured and all other minor spelling mistakes was noted and corrected.

e. At this stage the team reviewed and updated the project log book. After fine tuning few sections of the report, all the chapters were consolidated into one report including the DML, DDL codes as well access report.

f. All the members worked on their personal reflections and learnings from the group work and the project and the same was uploaded to the data modelling FB group.

g. It was enlightening to observe the varied outcomes and reflections identified by all the members and lessons absorbed during the course of last three months

h. The report and the project log were subjected to one final scrutiny and the same was uploaded by the project manager Mr. Johnny.

The meeting ended at 12.30pm.

d_pdm_report

Documents