Hi there,

I am trying to create a list of entities from some existing paper based forms.
I have made a list of what i thought was all of the entities but on further thinking they could be attributes.

for example, phone number, address, postcode i have put on my entity list but should the entity just be customer rather than the atributes?

Thanks,

madlan.

One person's entity is another person's attribute: it depends on your requirements. Take postcodes: for most requirements this is just an attribute of an address, but if you are designing a database for the Post Office they may think of it as an entity with attributes of its own (such as grid reference for example).

As a rule of thumb, if you don't have any interest in phones and postcodes per se, but just need a contact phone number and addresss for a person, then these are attributes.

Concur
But these sort of issues also arise in most db designs, for example:-

There are some designers who will contend that a person may have more than one phone number, so possibly these should be entities, I suppose it depends on your perception of the world you are trying to represent, and how open ended you think it may be. It could be a reasonable ssumption to suggest an individual has a specified limited number of contact points, say 2 tel, 1 fax 1 emal, others may contend that a person may have an open eded number and thereforeyou can't limit to an arbitary number, as there will alwasy be someone out there who breaks such rules.

There are also people who contend that the NULL value should never (or at best rarely used) as a NULL value indicates that that element should become an entity in its own right, personally I don't agree with that stance.

Many thanks. That helps a lot.
Another small problem i have encountered is the addresses table for my customer.

Each customer can have 2 addresses, 1 billing and 1 delivery.
Now the billing address cannot be NULL but the delivery address can, or should it contain the same as the billing address if they are they same?!

As far as table layout goes, should i have 1 table with a field signifying the difference or 2 tables, one for each address with an address table linking them to the customer?

I’m sure this must have been thought out many times considering the amount of ecommerce these days but i cannot find any information on this scenario.

Thanks again for your help,

madlan.

I have attached 2 erds of the two ways i can think of.

madlan.

I don't quite understand your solution #2... one address can be attached to many customers?

I did a design similar to #2. Customer has 1..N addresses with a "type" field to distinguish (as opposed to a flag - it's a bit more flexible as a "type"). In our system each customer has a Billing and Shipping address.