Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / General DB Topics / DB Theory / October 2008

Tip: Looking for answers? Try searching our database.

Simple database design question

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Mark S. (UK) - 30 Sep 2008 16:07 GMT
Hi all,
I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
in mobile phones).  I can add any number of sim cards to the "sims"
table and any number of mobile phones to the "phones" table.  Simple enough.

Rule 1: A sim card can either be in a phone, or not in a phone.  It
cannot be in more than one phone.

Rule 2: A phone can either have one sim inserted, or no sim inserted.

So the relationship between the phone and sim is 0:1 to 0:1, I think..

There's several ways I could implement this, but the two most obvious to
me so far are:

### Method 1

SIMS table:
sim_id

PHONES table:
phone_id
phone_sim_id references sims(sim_id)

### Method 2

PHONES table:
phone_id

SIMS table:
sim_id
sim_phone_id references phones(phone_id)

So problem number 1 is, which way round makes more sense?  My first
instinct was method 1.  It seemed to make sense to say "the phone has
this sim card", though I suppose you could just as easily turn that on
its head.

Problem number 2 is, using either method above can break the rules and
create an impossible situation.  For example, several phones could
reference the same sim card in method 1, and several sim cards could
reference the same phone in method 2.  Would the proper way to ensure
integrity in this case be to add a "unique" modifier to the reference
field?  e.g:

phone_sim_id references sims(sim_id) unique

Any advice on the above would be much appreciated.

Thanks,

Mark.
Bob Badour - 30 Sep 2008 17:23 GMT
> Hi all,
> I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 33 lines]
> this sim card", though I suppose you could just as easily turn that on
> its head.

Neither of the above handle both 0 cases.

> Problem number 2 is, using either method above can break the rules and
> create an impossible situation.  For example, several phones could
[quoted text clipped - 6 lines]
>
> Any advice on the above would be much appreciated.

If one thinks about the relations above as predicates instead of as
tables, one naturally creates a much better design than either of the above.
Mark S. (UK) - 30 Sep 2008 20:24 GMT
>> Hi all,
>> I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 36 lines]
>
> Neither of the above handle both 0 cases.

In method 1, if phone_sim_id is NULL, then is it not related to 0
records?  Or am I missing something?

>> Problem number 2 is, using either method above can break the rules and
>> create an impossible situation.  For example, several phones could
[quoted text clipped - 10 lines]
> tables, one naturally creates a much better design than either of the
> above.

So the predicate would be "phone xxxxx uses sim xxxxx"..

Could you elaborate a little more or maybe direct me at some text that
might help?  Or another hint?  I would like to figure it out for myself
if I can, but I think I'm mentally stuck in one way of thinking here; I
can only think of relating the two items of data either as I've
described above or using a dedicated relation table.. or possibly an index.

How about:

PHONE:
 phone_id

SIM:
 sim_id

RELATION:
 phone_id
 sim_id

unique index on phone_id, sim_id ...

Am I at least on the right lines?

Thanks,

Mark.
--
Bob Badour - 30 Sep 2008 21:03 GMT
>>>Hi all,
>>>I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 39 lines]
> In method 1, if phone_sim_id is NULL, then is it not related to 0
> records?  Or am I missing something?

Yes, you are missing a healthy aversion to NULL.

>>>Problem number 2 is, using either method above can break the rules and
>>>create an impossible situation.  For example, several phones could
[quoted text clipped - 34 lines]
>
> Am I at least on the right lines?

Only one (compound) candidate key?
marks@alienmuppet.com - 30 Sep 2008 21:16 GMT
> >>>Hi all,
> >>>I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 41 lines]
>
> Yes, you are missing a healthy aversion to NULL.

I had the feeling you were going to mention that :-)  I have been
wrestling with myself on that.  For years I had an aversion to NULL.
ALL of my fields used to say NOT NULL next to them in my definitions,
however it seemed a useful way of saying "this object is not yet
associated" ...

As far as I'm aware, there are two alternatives; 1) having a dummy
object that unassociated objects are related to... OR having a
separate relation table to associate the objects, and without an entry
in that relation table, there is no relation.  That way, I could get
rid of using NULL.

Most of my fields are at least still NOT NULL.

> >>>Problem number 2 is, using either method above can break the rules and
> >>>create an impossible situation.  For example, several phones could
[quoted text clipped - 36 lines]
>
> Only one (compound) candidate key?

Sorry, I have missed out some important information:

PHONE:
 phone_id (PK)

SIM:
 sim_id (PK)

RELATION:
 phone_id
 sim_id

unique index on phone_id, sim_id

So now I've got a couple of primary keys as well as the compound
index..

Mark.
--
Bob Badour - 30 Sep 2008 23:02 GMT
>>>>>Hi all,
>>>>>I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 116 lines]
> Mark.
> --

I suggest you reconsider your constraints. Can a sim be in two phones?
Can a phone contain two sims? Does the index you created enforce your
requirements? What are the candidate keys of RELATION?
paul c - 30 Sep 2008 23:08 GMT
...
> Sorry, I have missed out some important information:
>
[quoted text clipped - 12 lines]
> So now I've got a couple of primary keys as well as the compound
> index..

PMFJI, but don't you mean two unique indexes for RELATION, one on
phone_id and one on  sim_id?   (I gather that the typical sql dbms
doesn't support candidate keys, so one must use physical features if one
wants to minimize the number of tables.)
Mark S. (UK) - 30 Sep 2008 21:21 GMT
>>>> Hi all,
>>>> I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 84 lines]
>
> Only one (compound) candidate key?

Those two posts from "marks@alienmuppet.com" are from me Bob.  I had to
switch to using google groups to send posts as my ISP's news service
went down temporarily.

Mark.
marks@alienmuppet.com - 30 Sep 2008 21:08 GMT
> > Hi all,
> > I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 49 lines]
> If one thinks about the relations above as predicates instead of as
> tables, one naturally creates a much better design than either of the above.

I have thought of another solutions where the primary key of the sim
table is also a foreign key that relates to the phone table : -

PHONE
 phone_id (PK)

SIM
 sim_id (PK, FK PHONE(phone_id))

Unfortunately though that stops the sim card being able to exist
without being related to a phone, since the primary key must not be
null.

The whole idea is that sim cards and phones can be bought and added to
the database.  At some point, the sim can be associated to ONE phone
(and that ONE phone can only be associated with that ONE sim).  The
phone cannot have many sims, and the sims cannot have many phones.

Method 1 is working at the moment:

PHONE
 phone_id (PK)
 phone_sim_id (FK SIM(sim_id) UNIQUE)

SIM
 sim_id (PK)

This is ensuring the integrity of all the rules I've mentioned,
however from what you've said I feel I may be missing something, and
may well kick myself once I figure out what it is....

Mark.
--
JOG - 01 Oct 2008 01:40 GMT
> Hi all,
> I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
> in mobile phones).  I can add any number of sim cards to the "sims"
> table and any number of mobile phones to the "phones" table.  Simple enough.

Here you have described two unary predicates: "exists_sim(sim)" and
"exists_phone(phone)".
Congratulations you have identified you're first two relations.

> Rule 1: A sim card can either be in a phone, or not in a phone.

Here you have identified the binary predicate: "contains(phone, sim)"
This is you're second relation. I think we'd agree the items in this
relation must exist... great, we have relations that state that
already, so two foreign key constraints linking to them are required.

> It cannot be in more than one phone.

Here you have identified a first uniqueness constraint on the
"contains" relation.

> Rule 2: A phone can either have one sim inserted, or no sim inserted.

And there's your second uniqueness constraint on the "contains"
relation. Implement them and job done - and with not a null in sight.
Breaking your problems down into predicates in this fashion is always
the way forward

Now tell me what would happen if a phone was deleted from the
"exists_phone" table?

> So the relationship between the phone and sim is 0:1 to 0:1, I think..
>
[quoted text clipped - 38 lines]
>
> Mark.
paul c - 01 Oct 2008 03:53 GMT
...
> Now tell me what would happen if a phone was deleted from the
> "exists_phone" table?
> ...

Heh, I imagine some OO pgmr would need to write a new method, but I
don't know that for sure, thank goodness.
David BL - 01 Oct 2008 04:56 GMT
> > Hi all,
> > I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 3 lines]
> Here you have described two unary predicates: "exists_sim(sim)" and
> "exists_phone(phone)".

Just a rather off topic comment...  One time on this ng I discussed a
unary predicate like this that stated that such and such exists, and
was beaten over the head for being metaphysical.   However I don’t
think there is anything wrong with using the term "exists" as long as
it is understood that the external predicate is in fact something more
specific – such as

exists_phone(P) :- phone P was manufactured by Acme Corporation.
Bob Badour - 01 Oct 2008 21:20 GMT
>>Hi all,
>>I have 2 tables, "sims" (as in mobile phone sim cards) and "phones" (as
[quoted text clipped - 26 lines]
> Now tell me what would happen if a phone was deleted from the
> "exists_phone" table?

Perhaps more urgently, what would happen if a sim was deleted from the
SIMS table?

>>So the relationship between the phone and sim is 0:1 to 0:1, I think..
>>
[quoted text clipped - 38 lines]
>>
>>Mark.
-CELKO- - 01 Oct 2008 20:09 GMT
I'd bet that you don't call the industry identifier a "sim_id" -- is
it a sim_nbr or something?? Ditto for a phone number; I think that is
15 digits in the CITT standard.  Learn to use the right names for
things, so you can have data interchange, a data dictionary, etc.

CREATE TABLE Sims
(sim_nbr CHAR(n) NOT NULL PRIMARY KEY,
..);

CREATE TABLE Phones
(phone_nbr CHAR(15) NOT NULL PRIMARY KEY,
..);

Put the sims in the phones ..

CREATE TABLE PhoneSimAssignments
(sim_nbr CHAR(n) NOT NULL UNIQUE -- industry standards?
  REFERENCES Sims(sim_nbr)
  ON DELETE CASCADE,
phone_nbr CHAR(15) NOT NULL UNIQUE
  REFERENCES Phones(phone_nbr)
  ON DELETE CASCADE,
..);

Use a view to show the sims status of all phones

CREATE VIEW PhoneAssignments (..)
AS
SELECT sim_nbr, phone_nbr, ..
 FROM Phones AS P
      LEFT OUTER JOIN
      PhoneAssignments AS A
      ON A.phone_nbr = P.phone_nbr;
xyzzy - 03 Oct 2008 03:56 GMT
> I'd bet that you don't call the industry identifier a "sim_id" -- is
> it a sim_nbr or something?? Ditto for a phone number; I think that is
[quoted text clipped - 29 lines]
>        PhoneAssignments AS A
>        ON A.phone_nbr = P.phone_nbr;

This ticks all the boxes as far as I can see.  The original
requirement was for only 1 SIM associated with a phone.
This requirement might not be correct -- even if he is selling phones
with one SIM & phone per box.
You can get phones that use more than one SIM, eg. Cect HT-508 dual
SIM mobile phone.

What if you can have 0, 1, or 2 SIMs associated with a phone?
xyzzy - 03 Oct 2008 04:51 GMT
> > I'd bet that you don't call the industry identifier a "sim_id" -- is
> > it a sim_nbr or something?? Ditto for a phone number; I think that is
[quoted text clipped - 38 lines]
>
> What if you can have 0, 1, or 2 SIMs associated with a phone?

S'pose you could add slot_number to PhoneAssignments and make it not
null, check slot_number in (1, 2).
Mark S. (UK) - 07 Oct 2008 11:26 GMT
>> I'd bet that you don't call the industry identifier a "sim_id" -- is
>> it a sim_nbr or something?? Ditto for a phone number; I think that is
[quoted text clipped - 38 lines]
>
> What if you can have 0, 1, or 2 SIMs associated with a phone?

That can never happen in the scenario I am dealing with.  They are not
actually phones; they are devices that take sim cards, and those sim
cards are put inside the devices and screwed shut before being sent out.
 Only engineers belonging to the company should have access to them,
and they'd only be changed upon failure.  I just wanted to provide a
more familiar scenario in my original question.

Thanks for your ideas and insight everyone, you've been very helpful.

Mark.
--
patrick61z@yahoo.com - 31 Oct 2008 21:21 GMT
> > I'd bet that you don't call the industry identifier a "sim_id" -- is
> > it a sim_nbr or something?? Ditto for a phone number; I think that is
[quoted text clipped - 38 lines]
>
> What if you can have 0, 1, or 2 SIMs associated with a phone?

He's probably working for Apple.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.