Contact List Database

Database Design

Introduction

• The purpose of each of the tables as well as

their relationships between the other tables

connected to them is explained.

• Design considerations to make the database as

flexible as possible are also outlined.

Business Issues

• This is only a generalized contact list that can be used - not only for personal use - but for any business application as well.

• If the database is used standalone and not integrated into any other particular database, it can still be used effectively on its own.

• This database also has the advantage of being used as an e-mail address book, with no limit to the number of e-mail addresses that can be added for any individual contact.

Database Tables

• This database contains 10 tables:

Company

Address

Phone

Device

PhoneList

Extension

Contact

E-mail

Information

Category

ERD

• The ERD for the database shows all tables and

their relationships.

• Link: ERD Diagram.

Table Design & Relationships

• The design of each of the tables and their relationships to each other is explained.

• The design considerations to make the database as flexible as possible so the user does not run into limitations that can restrict its use is also presented.

• More importantly, the business considerations & scenarios that influenced the database design will also be explained.

Company Table

• The Company table contains the name of the company the contact works for, if it applies.

• This table contains two records to start: “Home” and “Work”.

• “Work” can be used if the name of the company the contact works for is not known. For example, the phone number of the contact may be known, but not the name of the company. “Work’ can be used as a placeholder to indicate that this is specifically a work and not a home number.

• “Home” is used to specify someone’s home address and phone number in the tables that follow afterwards.

• Since the company ID is used as the FK in the Address table, if a contact’s company is not known, the “Work” record must be referenced as a placeholder to maintain referential integrity.

Address Table

• The address table contains the address of the company the contact works for.

• If this is the home address of the contact, then “Home” will be used as a placeholder for the company name in the Company table to maintain referential integrity.

• If the address of the company is known, but not the company name, then the “Work” record in the Company table will be used as a placeholder to maintain referential integrity.

• The Address table contains fields for the mailing address, city, province and postal code.

• There is a one-to-many relationship between the Company and Address tables as shown in the ERD. For example, one company may have several branch addresses.

• This table also contains two records to start. This table also has “Home” and “Work” records. The reason is to maintain referential integrity with the Phone table.

• For example, it is possible to have a contact’s phone number without knowing their address. The Phone table contains the address ID of the Address table as a FK. Therefore, to maintain referential integrity, a record must be referenced in the address table. Referencing “Home” or “Work” will be sufficient if the contact’s address is not known.

Device Table

• Devices are the types of equipment that will function over phone lines. The following are listed in this table to start:

Phone (landline)

Cell

Fax

• The device IDs in this table are used as FKs in the Phone table to specify the type of device used. For example, whether the number is a phone or fax number.

• There is a one-to-many relationship between this table and the Phone table because many numbers can be listed as phone numbers, fax numbers, etc.

Phone Table

• This table holds the contact’s phone and fax numbers.

• The address ID and device ID are foreign keys in this table.

• In this way, the contact number specified is associated with the referenced company and particular branch location.

• The device ID specifies whether the number is a landline, cell or fax.

Phone Table Primary Key –

Avoiding a Compound PK • It is important to note that the address and device IDs, although they are

foreign keys in this table, do not form a compound primary key.

• The reason is so that more than one contact number can be recorded for the same device type.

• For example, two cell phones may be issued to an employee by a business – maybe the different services offered by one phone manufacturer are preferred over the other.

• The phone numbers will be different, but the branch address the employee works out of will be the same.

• Also, the FK indicating the device type – cell phone – will also be the same.

• If these two FKs formed a compound primary key, this condition will be rejected by the DBMS.

• Not creating a compound primary key on these two fields does not impose a limit on the number of any one device type – in this example, cell phones – assigned to any one contact.

Phone Table Primary Key – Phone

Number Cannot Be PK • The primary key for this table is just an auto-incremented integer and is

simply labelled phone_id.

• The phone number will not sufficiently serve as the primary key.

• The reason is that phone numbers can change sometimes.

• If someone changes their phone number, this means that the phone number primary key has to be changed – not just in the Phone table – but in other tables where the phone number is used as a foreign key.

• Having to change the phone number in more than one place can be very messy. Even though cascade updates can help make this problem easier to resolve, not all databases support cascade updates.

• Assigning the integer value mentioned above as the primary key means that the primary key value is not affected by factors outside the database. Therefore, the auto-incremented value used above will not change over the course of time.

Phone Table Relationships

• There is a one-to-many relationship between

the Address and Phone tables.

• Any number of contact numbers of any device

type can be listed for a contact.

PhoneList Table

• This table connects the Phone table to the Contact table as a bridge entity between the two.

• This table implements the many-to-many relationship between the Phone and Contact tables and contains the primary keys of both tables as foreign keys in this table. These two FKs also form the compound primary key.

• The reason this is a many-to-many relationship is two-fold:

Any single contact can have many phone numbers, regardless of device type.

One phone number can also be assigned to several people in an office. In this case, everyone has the same phone number, but each are assigned individual extension numbers.

Extension Table

• This is the extension number of the referenced phone number, if applicable.

• This is only a one-to-one relationship because any single phone number will only have one extension number.

• The width of the extension number field is set at 30 characters wide because not all extension numbers are four or five characters wide.

• Some phone lines are navigated by voice recognition. For example, someone may say “Accounting Department” so that the caller will be directed to the accounting department instead of typing in an extension number. Therefore, “Accounting Dept.” would be entered into this field for future reference.

Contact Table

• The contact being referenced is entered here.

• Both the contact’s first and last names are

entered.

E-mail Table

• This holds the contact’s e-mail addresses.

• There is a one-to-many relationship between the Contact and E-mail tables because a contact may have more than one e-mail address. For example, both the contact’s personal and business e-mail addresses may be entered.

• As many e-mail addresses can be entered for one contact as is necessary.

• Some e-mail address books put a limit on the number of e-mails that can be listed for any one contact. Again, in this database, as many e-mails can be entered as is necessary. For example, some people use different e-mail addresses for different purposes. A part-time college instructor would have personal, business and college e-mail addresses.

• The contact list database also serves as an e-mail address book as well as a phone book. In fact, if no company, address or phone information were entered, this database can also serve as a stand-alone e-mail address book.

• The reason for this is that the E-mail table is completely isolated from the company, address and phone tables. There are no dependencies between any of them. This table’s only connection is with the Contact table.

Information Table

• This contains any additional information on a contact.

• For example, the hours the contact is available in their office. Also, a contact’s Facebook page or Twitter account may be listed here as well.

• There is also a one-to-many relationship between the Contact table and this table. As many details can be listed for a contact as is necessary.

Category Table

• Contacts can be categorized as necessary. Any number of categories can be entered and used as is required by the business or for personal use.

• For example, a personal contact list can contain Friends, Family and Business as categories. A business contact list can contain Underwriting, Claims and Brokers categories for an insurance business.

• There is a one-to-many relationship between the Category and Contact tables. Any number of contacts can be listed under a single category.

Advantages

• The biggest advantage of this database is that

the information that can be entered into it is

not limited in any particular way.

• Any number of phone numbers, for example,

even multiple cell numbers for a single person

can be entered.

• This database was designed to be as versatile

as possible.

Next Presentation

• Next, how the contact list database’s

capabilities can be expanded to support other,

more application-specific databases will be

discussed.

• Next slide show: Database Expansion.

• Project Web site: Database Design.