zero2

I'm creating a database for my m$ access class, well actually its final project which I decided to do early. The requirements are that the database needs to have at least 2 tables, 2 form, 2 reports, a few queries. Macros & and a Switchboard are extra credit.

The database I'm creating is a spyware database.

So far I know for sure that I want a spyware table a table containing different types of spyware, and a antispyware table containing a list of products that remove spyware.

I've created a a table known as Spyware, the fields are as follows:

Spyware ID, Name, Category, Threat Level, Description, Information URL, Symptoms, and Removal Tool.

A typical field would have the following info:

AD01 | 123mania | Adaware | 3 - Moderate (based on a 1 - 5 scale) | Program that creates advertisments | hxxp://www.123mania.com/ | Changes browser, opens ports, shows ads. | X-Cleaner |

Anyhow the problem is that I want duplicate my primary key, because I want to have more removal tools such as the following:
----------------------------------------------------------------------
AD01 | 123mania | Adaware | 3-Moderate | Program that creates advertisments | hxxp://www.123mania.com/ | Changes browser, opens ports, shows ads. | SpyBot Search & Destroy |
----------------------------------------------------------------------
AD01 | 123mania | Adaware | 3-Moderate | Program that creates advertisments | hxxp://www.123mania.com/ | Changes browser, opens ports, shows ads. | SpySweeper |
----------------------------------------------------------------------
Is it possible to do it like above?

Or should I just create another field such as:
Spyware ID, Name, Category, Threat Level, Official Description, Information URL, Symptoms, Removal Tool, Removal Tool.

I guess what I'm asking is which makes more sense?

Lebell

By definition a primary key is unique.

In order to make this table into 3rd normal form (which most db tables should be), you need to take anyon extra info that appears multiple times and put it into a table where it exists ONCE.

That info should have a unique identifier (ie, the primary key) that is used in another table to connect it to related fields.

In your case, you should have something like:

identifier1(primary key)|AD01|123mania|adaware.....

in one table and then create another table with

identifier2(primary key)|identier1(foriegn key from above)|SpySweeper
etc.

The foreign key in your second table is the key to linking the data.

You could also do it like you suggested by creating another field, but I suspect you would get points knocked off since the proper way to do it is to create another table.

__________________
"Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience." – C. S. Lewis

The ONLY sponsors we have are YOU!

Please Donate!

zero2

I'm not sure if this is what you were thinking, but this is what Im going to do.

I'm going to create create multiple tables. One table will be called Spysweeper, another Spybot Search & Destroy, another will be called M$ antispyware. This will probably solve the primary key problem. I only hope that I can copy the table so that I don't have to retype everything again.

So this is what it would look like:
Search & Destroy Table
AD01 | 123mania | Adaware | 3-Moderate | Program that creates advertisments | hxxp://www.123mania.com/ | Changes browser, opens ports, shows ads. | SpyBot Search & Destroy |
----------------------------------------------------------------------
Spysweeper Table
AD01 | 123mania | Adaware | 3-Moderate | Program that creates advertisments | hxxp://www.123mania.com/ | Changes browser, opens ports, shows ads. | SpySweeper |
Thanks:)

Moskie

If I understand what you're saying, zero, that's most definately *not* what you want to do. Are the concepts that Lebell mentioned about using foreign keys to link tables completely new to you? Not sure what this class of yours is for, but those are standard database design concepts.

The proper way to do this is with 3 tables:

"Spyware" table
"Anti-Spyware Software" table
"Anti-Spyware Software Removes Spyware" table

The first two are straight forward, each having their own primary key. The third one would be structed like this:

Primary Key Field (autonumber)
SpywareID (number): foreign key to spyware table. the number stored represents a record in the spyware table.
Anti-SpywareID (number): forign key to Anti-Spyware table. The number stored represents a record in the anti-spyware table.

So a record in the third table could simply be:

1 | 5 | 10

What that says, is that the spyware record with primary key of 5 can be removed by the anti-spyware software with a primary key of 10. You could have another row that has:

2 | 5 | 12

This shows you that spyware 5 can *also* be removed by anti-spyware software 12. This would be the proper way to store this information....

__________________
Greetings and salutations.

Lebell

What Moskie said.

Again, you shouldn't have to be retyping data.

If you are, then you aren't doing it right.

__________________
"Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience." – C. S. Lewis

The ONLY sponsors we have are YOU!

Please Donate!

zero2

I was kind of going over the logic that I had mentioned, and at first I thought it sounded like a good idea, but the more I thought about it, it really wasn't what I originally wanted to do, and my database would be pretty one-dimensional, that you could probably do in Excel.

So I came back here to re-read what Lebell had posted, and I finally understood what you were trying to tell me. I also like Moskie idea about adding a 3rd table, since originally I had planned to put spyware removal on the spyware table.

Thanks for your help, Moskie & Lebell.