Question Need Help in Correcting Design and Possible Flaws :/

arr0w

New member
Local time
Today, 08:47
Joined
Mar 10, 2014
Messages
5
Okay, Im relatively new to Access and Im trying to create a database for Characters/People. Ive worked with an older version back in highschool- like as in what i see in a lot of vanilla examples; a Customer table with ID as key, Name, address, phone, ect,, a Product table with ID as its key but linked to Customer table by customer ID, ect. I could probably do something as simple as that. Now, for my needs, I want a database/tables containing Name, age, height, sex, description, and a couple other fields specifically related to the character. Also, i need a table for animal names, species, and age.

Ive figured out a fair amount of how to enter all of this multiple ways, but not one way that enables everything else like form building to work properly, let alone queries or reports. On top of that, i want another table containing character specific description info. id prefer to have a male and female version of that table so i dont have everything lumped together on one and from what ive seen, you SHOULD split info into multiple tables, thats the point.

Sorry for the long description, i know bits and pieces of what i need but not specific what to ask for help for. This is also why im posting here, since its about all aspects. Would some kind soul take a look and see if what ive got so far can become workable or possibly provide a brief working-example once looking at what i have, to get an idea of exactly what i want? Pleaseeeee lol im at this point right now :banghead:
 
A wise man once said to his wife, Marge Simpson, "Close, but you're way off".

Read up on database normalization (http://en.wikipedia.org/wiki/Database_normalization). Run through a few tutorials. You do want multiple tables, but they must be logical, you don't put information in different tables because they differ on one aspect. Instead, you make that aspect a field and contain the data there, then when you want just the records that have a certain value for that aspect, you build a query. That means, you don't need tables to seperate the genders, you need a field to hold the gender data.

Again, database normalization (http://en.wikipedia.org/wiki/Database_normalization), that's the first step for every database, worry about that, then start thinking about forms.
 
Wait- i THINK kinda get what your saying but im not sure how to apply it to this specifically to my information. For example, in my mind, im looking at how i would've set it up in Excel. In a way i get what you're saying until i get to the point of separating it out to the individual characters or IDs.

I had this typed and then it stopped making sense: :banghead::banghead::banghead: (((So basically, probably what im trying to use as my Tables, i need to actually be using as my field entries??? O.o So rather than: tblCharacterData:
[My Field Labels] ID, Name, Height, Weight, ect, and having the respective info in the cells,, i need to have it like: tblHumanData:)))

or are you saying i need a table, for example, for Human and animal, The animal one containing the fields Name, Species, Gender,, the Human one likewise and then have a form to fill in the information? Ive been approaching it by grouping (or attempting to anyway) Say, tblSpecies: with a key field and a Species field with the entries, Horse, Dog, Cat and a tblAnimalCharacters: key field and a Names Field.

I hope at least some part of that made sense for someone to clarify the right way to go about it for me. Ive been reading on Normalization but i think im thinking about it backwards. Go figure. I can come up with ingenious solutions and workarounds when modding skyrim, but i cant wrap my head around this. ><
 
You may need multiple tables for humans, characters and animals--you have to think about the data you are storing for each object. If they all have the same properties you want to capture (height, weight, IQ, etc.) then they all go in the same table. If you want to capture different data based on the type of entity it is (Humans - job, favorite color, SSN: Animals - species name, domesticated, weight) then you use 2 tables.

Since you are familiar with Excel, start there. Draw up a few sample records for each object type. Make a column for each property you want to capture, then see how similar the column names are for each type of entity. That will determine how to structure your data. Run through that exercise and post back your spreadsheet along with what you think your tables should be.
 
Okay, now i think i see what you were getting it. I was, as i should've known from the beginning, making it wayyyyyy more complicated than i needed it to be. As for the suggested exercise, I havent slept yet and im about to so i will do that later when i get the time and post back then. However, i would like to ask one more question, so that a) maybe i could implement it in the spreadsheet too and b) so its hopefully answered for when i get to that point. is it possible if i WANT to, to have some data specific to, say, males height/weight on a separate table and link through relationship to the character? or is that just going against normalization (and causing my problems)? If its going against, is it because i can get the information organized like that through use of queries? Note, i know THAT would be illogical, unless i was going to put every possible height/weight possibility. And it would still be illogical. im asking hypothetically cause, again, im accustomed to separating it all out manually, not consolidating it like this. If im thinking correctly now, i was trying to split it all up when really, i needed to condense it more. So when would another table linked by a relationship come into the picture with this scenario? What fields would warrant a separate table then? and, given this process, for example would it be okay if i end up with a, say human character table, where there are fields that get filled in for female but not male?
 
Last edited:
I can't discern what you are asking actually, but in both interpretations my answer is no you shouldn't have that data in a seperate table, you would just put it in the same table you were storing the other attributes.
 

Users who are viewing this thread

Back
Top Bottom