I would recommend adding a tutorial group entity and a student assessment entity. I would remove the name attribute from the lecturer entity and add it to the staff entity. Lastly I would add a...

Here are some recommendations I have:

1) Remove the car_id field from the buyer table; what is the purpose of that field?
2) Create a table to track the make of the car; instead of typing in the...

Yes, that looks good to me.

I would strongly recommend creating tables from scratch and not from imported spreadsheets. Spreadsheets usually won't be divided into the database structure you need.

As far as importing data......

As far as building queries, once I know what result I'm interested in, I start with one table as my 'base' table. In the query I provided to you, I used 'people' as the base query.

From there, I...

Here is a SQL statement to produce the results you asked for:


SELECT person.first_name, person.last_name, activity.activity_name, session.date
FROM ((person LEFT JOIN attendance ON person.id =...

Just wanted to let you know that I did look over those screen shots and everything looks good to me.

If the only change you made was to insert the session_activity table, then you should be able to just drop that table; however, if it is easier to start fresh, you can drop all the tables and create...

Please note that there should be a one-to-many relationship from activity to session_activity and a one-to-many relationship from session to session_activity. The code you supplied looks correct,...

With the design I had in mind, there is only a one-to-many relationship from activity to session. For example, I am a physics lab instructor. For each physics lab course (activity), I teach 13...

It looks like you have been busy and made good progress. Before I go in to anything else, I noticed that the design I suggested is missing one crucial field.
The attendance table should have three...

Just so I am clear on the issue; for a particular acquisition, it is okay to have two acquirees, but there can only be one acquirer. Further, you want the databaes to prevent the user from entering...

The activity table that I suggested is simply the date_time table you had but with the addition of the activity id to track for which activity the date and time was for.

You mention that there is...

I don't see a need for the master_id. Could you explain it further? The problem I have, for example, is that the date and time of an activity is not related to the people.

Here is the design...

1) The two database management systems I would recommend are MS SQL and MySQL. Both are very stable and are widely used.

2) I agree with the single database approach. All related data (i.e. a...

Just thinking outside the box a little... you could use a program that gives you remote access to a computer, such as PC anywhere, or by using VPN.

Of course, you can always use MySQL or MSSQL,...

If salary is based simply on position, you can have a position table that stores all the positions and salaries related to each position. You can also have a table to track the history of employment...

I believe MS Access would be a good way to go with the description you mention above. Other possibilities are MySQL and MSSQL; however, that would, in my opinion, require more work than is needed...

I would actually go with MS Access for these reasons:
1) Easy to set up (the entire database is in one mdb file and you just need the Microsoft Access Runtime to use the database). There is no need...

I would recommend a new table that has fields to track the following:

Room, Customer, Check-In Date, Check-Out Date

I think a zero-to-many relationship between between employees and enrollment is appropriate; however, I believe MS Access treats a zero-to-many relationship as a sub-type of the one-to-many...

You mention that you think the relations are many to many. Can you tell us which tables you think have a many-to-many relationship. From the tables in the database, it seems it would be appropriate...

I would recommend the "lookup table" approach. This will save you from creating many tables that serve the same purpose and it will make queries easier to build since you don't have to remember...

I would say that the number of fields in a table has very little impact on database performance. I don't think you will notice a difference between the query speed of a table with just a few fields...

I would recommend by starting with the following tables and fields:

Parent/Guardian: Id, Last Name, First Name, etc.
Child: Id, Last Name, First Name, Date of Birth, Etc

Child-Parent/Guardian:...

The most "proper" way to set this database is to have one table that stores all the people. Using two tables would not follow normalization rules.

The table that stores the people would only...

I would recommend the following partial database structure:

People: Id, Name, Address, Etc...
Client: Id, PeopleID, Etc...
Staff: Id, PeopleID, Etc...

The People table will store basic info...

Cleaning up a database with bad data will usually cost more money and time than programming a database that will not allow users to add bad data. Therefore, I usually recommend programming the...

You should use the type_ID in the schools table. This will allow the name of the type to change without affecting the data. Granted, in this case, I doubt the name will change, so you should be...

You will need to create a RoomsTime entity. This entity will have two attributes: RoomsID and TimeID. You then need to make both of them into the compound key for the entity. This will ensure that...

Those are two relationships, so showing both of them would be appropriate.

To answer your questions:
1) I would add an attribute to the Vendor table to track local or non-local
2) I would not add anything to the parts table to track assembled and subparts; that should be...

What are all the primary keys you are using? There may be a conflict in your use of primary keys.

Secondly, can each train go on only one journey? If not, then I would recommend using the...

It appears that there is a many-to-many relationship between the supplies and events (each event can have more than one supply and each supply can be used for more than one event). If that is the...

The particulars will always be determined by your database needs, however, it is rather common for each different table to have its own ID, which is the primary key for the table. If a table has a...

You need a Supply ID primary key in the Supply table with event no and wedding no as foreign keys. The way you have it set up currently, each event/wedding can have only one supply (I'm assuming the...

Since the relationship between the tables is a one-to-many relationship, you do not need an intermediate table. You only need to have the following structure:

County: ID (PK), Name, etc.
Voting...

Strictly speaking, the table appears to be normalized since the fields with similar content is not the exact same content. However, I do like Stylish's recommendation.

I would recommend using a...

The main goal in designing a database is designing a database that works for your purpose. There are many situations where it is possible to make a database more properly normalized, but it may take...

If time is a large concern, then I would recommend MS Access since it is a lot faster to program in. If you save the database in a directory shared over a local network, then multiple users can...