Relationship linking for Laboratory procurement database, many-to-many relationship help

[truejay001]

First timer here. Table names are in parentheses.

I am running procurement for multiple laboratories (Labs). Each lab has multiple contracts (Contracts) with multiple vendors (Vendors). Furthermore, each vendor can potentially have multiple contracts with the same lab.

I have the following tables and their respective fields (* designates current primary key):

Contracts
- Contract Number*
- Vendor Names [(multiple vendors in this field(i.e. Vendor1, Vendor2, Vendor3)]
- Lab Names [multiple labs in this field (i.e. City1, City2, City3)]

Labs
- Lab Name*
- Vendor Names [(multiple vendors in this field(i.e. Vendor1, Vendor2, Vendor3)]
- Contract Numbers [multiple contracts in this field (i.e. Contract1, Contract2, Contract3)]

Vendors
- Vendor Name*
- Contract Numbers [multiple contracts in this field (i.e. Contract1, Contract2, Contract3)]
- Lab Names [multiple labs in this field (i.e. City1, City2, City3)]

What is the best way to link the data I have? I would like to avoid having to reformat the fields/tables, however I want to maximize the future fidelity of the database. Specifically, what is the best way to set up the relationship links for maximal efficiency? Many-to-many relationships seem to be the way, but I don't know how to get that to work out for me.

Any help is most greatly appreciated!

[orange]

Work through this tutorial to get some hands on experience with table design, normalization and relationships.
You save a lot of frustration by learning these concepts.

Good luck.

[truejay001]

I read the document, but I did not find any foreign concepts nor did I find anything to specifically answer my question (unless I am conceptually missing something). Thank you for responding to my post however.

[orange]

You have to work through the tutorial. He starts with a business description (problem definition if you will).
He then goes step by step into defining the things and their attributes. He goes through the process of normalization, and shows you how to identify the various components and why. He builds a normalized data structure with relationships that meets the business requirement. This is the blue print for the database.

You really have to work through it. Doing a casual read, is not going to help you with table structure or relationships.

This tells me you really need the tutorial.

Many-to-many relationships seem to be the way, but I don't know how to get that to work out for me.

Anyway, that's the best advice I have for you, and this.

Good luck.