I am currently designing a contact management database for a chamber of commerce. The goal of the database is to store all the person (except our own staff), all recorded companies (regular companies and member of the chamber), addresses of the person and companies, tasks that the staff are currently responsible for, a list of our staff (user) and the roles within the chamber.
Business Rules
- one
person
works for onecompany
- one
company
have multipleperson
person
andcompany
can have multipleaddress
- one
company
can be in multipleindustry
- one
industry
can have multiplecompany
- one
company
can have multiplemembertype
- one
membertype
can have multiplecompany
- one
user
can play multiplerole
- one
role
can be assigned to mutlipleuser
- one
user
can have multipletask
- one
task
can be worked on by multipleuser
- one
task
can target multipleperson
- one
person
can be targeted by multipletask
- one
person
can only be added by oneuser
- one
user
can add multipleperson
- one
company
can have 0 or 1parent_company
- one
parent_company
can have multiple child company
I have come up with the following design and it has undergone some changes:
Issue
- Are there better ways to display the
user-task-person
relationship? - For example, if a
person
can have only oneemail
but can have multipletel
, should I make an extra table just fortel
whileemail
is still in theperson
table? Would it considered to be “unclean”? - For the table
membertype
, shouldcompany_id
andtypename
both be PK? - How does this schema look now? Are there still some normalisations to be done?
I’m a newbee at database, there are definitely some design flaws or errors, it would be nice if you guys could give me some suggestions so that I can correct and improve this design. Thank you ^~^
Advertisement
Answer
The main issue I see is that while all primary keys are defined as Int some foreign keys or references are defined as varchar.
- company in contact table
- user_role in user table
- parent_company in company
- added_by in user table
Also role_id is length 10 while all other primary keys are 11.
Personally I would prefer capitalised table names, User, Company etc
Update for the edited version:
You might want to create a table for phone, mail,fax etc say contact_info
that could contain a string field holding the contact info and a type field (email, phone, fax,…). This way you could store several phone numbers for instance, if you want to limit email to one you could either leave it in the person
table and not allow it here or have a business rule to only allow one email row in contact_info
.
This table could also be useful for company
if you want to store email or phone numbers for the company
like contact@somecompany.com or the number to the company switchboard
For the table membertype, should company_id and typename both be PK?
Yes
Second update
About the address solution:
Shouldn’t the address
table contain enough info to make each address unique, I can understand that a company can have more than one address but should it allowed for two companies to have the same address (by that I mean the same row in the database) so maybe it should be changed to a one-to-many from company
and ´address´ but a one-to-one in the other direction.
I also think it could be good to have some kind of label in the two address-link tables so one can easily identify an address like “home”, “work”, “Office”, “Warehouse”…