Need a bit of help with my database

StuR

Registered User.
Local time
Today, 10:25
Joined
Jun 18, 2007
Messages
14
Hi all, newbie here so forgive the nature of my post, I've been searching around here all day and I'm a bit lost with a database.
Basically I'm fairly new to databases and I'm sat here armed with a fairly unhelpful book throwing myself in at the deep end. Sorry for the wordy post but if anyone who knows what they're doing could lend a hand I'd be eternally grateful. :)

I'm making a database for my girlfreind which records all required details of her work clients.

The database is for storing information relating to people my girlfreind helps with charitable work. In this there's all sorts of things covered from general information to basic details of the clients income and details of their utility bills and so on.

Basically the concept of relationships I've totally forgotten, always handy in a relational db.

1)
Ok, in each of the tables I've got the clients name and primary key (in this case their national ID number), and I've made a form for each of them to input the data. This seemed right before, but it doesn't now. She doesn't want one huge form to fill in so how can I get the name and NI number to automatically update the next form in the series? I'd assumed that as there's a chance one form may be required to be filled out and another might not be required, that it'd be good to have it featuring on each of them just in case.
2)
I want to make it so when you want to add details of a new client, it takes you through each of the forms in sequence, sort of like creating a new portfolio or profile from half a dozen forms. Is there an easy way to do this? I can't picture a link between the forms and switchboard / menu that would do this.
3) Relationships.
This is the bit I'm really stuck on at the minute. Textbook newbie I know, but I just can't see how my tables would be relational, which makes me think I've messed up the basic design.
Basically from the notes I've been given details of each of the clients utility bills. For each of this utilities there's a few things that need filling in, which are the same for the majority of the utilities. Access is asking me to sort relationships when I go to make a form which gives the list of all these utilities on one page. But I really can't see where or why a relationship would be valid on any of them.
I can see why a product code would be related to a supplier, but none of these are directly related to eachother that I can see, the only common denomonator being that they're relating to one person.


That's it for now, but if anyone who knows access well I'd be eternally grateful if someone would take a look at what I've done so far and let me know whether it's ok or if there's any glaring errors or point and laugh at where it could be improved etc, as it's something I've basically learned as I've gone along from scratch in a short space of time, so I'm not brimming with confidence. I can email it along with the notes, and it's basic as they come so doesn't have anything in like macros and so on. Looks kinda pretty so far though, but I'm sure anyone who half knows what they're doing will look at it in horror. :o

I've attactched a zip file with my work so far in, so it's not finished, but I figured it best to find out it's a hideous mess at this stage rather than doing the whole database then finding out. :eek: There's an excel spreadsheet in there I was given to use to give me some pointers as to what she wants incorperating.

Great fun learning about access, but it's a big learning curve and I've got a feeling I've taken the wrong :D approach with mine. :(

Thanks in advance to anyone who's willing to shed some light, I'm really enjoying learning about access and databases as a whole, but in doing so this way I'm confused.
Stu
 

Attachments

You need to start with 'normalisation'. That'll tell you about how to get the structure correct.

e.g. you never store text data (like client names) twice. It goes in a clients table and is allocated an AutoNumber, then the autonumber is the stored reference in the other tables.

Instead of having a "number of forms", consider using a tabbed form.

Remember to always have a query as the form's recordset not a table

That'll do for now - you've got a lot of searching on these forums to do

Look at the Northwind database and see how thats done (it's on the Access CD)

Col
 
I'd look but I can't open accdb...can you post as zipped mdb? (AC2000).
 
Thanks for that. I've taken a gander at the northwind database and currently have it open infront of me.

Bear with me as I'm not clued up as you're now more than aware, but would the best approach be to get rid of the tables I've got for various aspects, (income, general info, family composition etc) and create one large table from that?

My idea in using a few different forms was to set up a cascading system where upon completion of one form you get given another, as I was told by the missus that she wouldn't want the forms all completed in one go.
Would a tabbed form be the better option?

CraigDolphin.. I'll have a look now :)
 
hmmm for some reason it won't let me save as an older format because I'm apparantly using features of the new one. That won't work then lol.
I'll rip it across to an older format now, it's rubbish anyway so it won't matter if I lose bits at this early stage :)
 
Ok lets keep this simple

you need a table
name address, etc NI number (do not use this as a priamry key) use the PK Primary Key which will be autonumber on the table

now you have PK (priamry Key ) starting from 1
number 1 willbe unique and will be the first record on your table/dbase

in your second table what do you need ?

what I would do here is stop .
and write down on paper excalty what you want - information wise - don't worry about putting it together at the mo..
I do mine in a spreadsheet , so i can tick them off once done example


info require
Turnover - format currency
name of Employer - format text

now you can take this further and have required yes/no just add on to the columns al of the requirements per item - this will help in the long run


a list like this will help
1 get you data sorted
2 prod you into thinking do i need this

now if you think that you need to have the employer in two tables put a star next to it to represent possible duplicate (as the rule is don't store the same info more than once- by and large occassion there is a need to deviate from this - but not on what has been presented so far)

once you got this together - come back and either myself or someone who knows what they are doing will point you int he right direction .


gbp
 
To add a little to Gary Panic's thoughts, once you have identified all the information you need, you should think carefully about what tables you will need and how they relate to the other tables (one to one [rare]; one to many; or many to many)

You should have a table for every 'entity' that you wish to track. Then, you may also need junction tables to link entity tables that have a many to many relationship.

A cursory scan of your spreadsheet reveals several entities:

People
Utilities
CommunitiesOfInterest
IncomeTypes
Referals
Issues

There may be more depending on the real-world rules that apply.
The People table would something like:
PeopleID (Autonumber, PK)
PeopleFirstName
PeopleLastName
PeopleAddress
PeopleHomePhone
PeopleWorkPhone
PeopleCellPhone
PeopleEmail
etc etc

IncomeTypes would have something like:
IncomeTypeID (autonumber; PK)
IncomeTypeName


Now, an example of how a junction table would work could be between the People table and the IncomeTypes table. You need a junction table because many people could have many income types. Let's call it PeopleIncomeTypes.

This table would contain :
PeopleIncomeTypesID (autonumber; PK)
PeopleID (FK)
IncomeTypeID (FK)

So, for every person there would be a line in this junction table for each type of income that they have. If they have no income, there's no line in the table for that person. If they have 5 income types, then there'd be 5 lines in the junction table.

There are lots more potential junction tables suggested by your spreadsheet.

Do some reading on normalization (a search here or on google should get you started).
 
sorry for the delay in getting back on this one, work's been crazy.

Finally seem to be getting somewhere with this database, done a bit of searching and reading and I'm actually starting to understand it which is nice, certainly helps.

Craig and gary, massive thanks for the advice above guys, it's been invaluable so far and has really helped my understanding of the very basics. I'm in debt to both of you :)

I still trying to get to grips with junction tables hopefully it's just a case of a bit more reading :)
 
Last edited:
Just a quick question, I just want to make sure before I end up having to undo loads of work, using junction tables and the like will be fine in access 2000 won't it?

I'm using access 2007 and the system it's to run on when completed is 2k, and as I've not much previous experience I'm not too sure what I can and can't use for a 2k based database :)
 
Junction tables are inherant to any relational database where many to many relationships are required. I use A2K myself.
 
Just when I thought I had it the wheels have fallen off so to speak...

Ok basically I've hit a monumental brick wall and I'm fast running out of time on this one to the point where I'm considering offering payment to someone to do it, but as I'm poor it looks like being a stress filled day as that's not an option. Any ideas how much it would cost to make this database a reality bearing in mind everyone I've asked has said it's very simple and uncomplicated and that I'm just an idiot!
Anyway, here's what I'm stuck with....

So far my database has 2 tables. Flying aren't I? lol.

One of them, the clients table, contains all the information about the client thats shown on the first page of the spreadsheet found in the zip file i attatched above. This makes for a very long table but I'm told it's not a problem as it's only for the data entry side of things on one form so I'm happy with it. (bear in mind this is just for my girl's private use for storing simple data and running simple reports and stuff on her clients).

In the second table I have utilities as per the second page of the spreadsheet. for this I'm using giving each utility it's own ID using the primary key, and using a drop down list / listbox to select the type of utility (gas water electric etc).
This table also has the non priority debt incoperated into it as I couldn't see a reason to have it elsewhere.

The trouble I'm having is that is seems to me that everything else seems better off as a spreadsheet, I cant see a reason for a unique identifier in anything other than the tables I mentioned above, the issues table for example. I know I clearly don't understand something here but I'm really having a hard time getting my head around it, It just seems like I'm wasting my time trying to get what seems to look ok in spreadsheet format transposed into an effective, simple, working database.

Right, I've looked at relationships and as far as I'm aware I've got them sorted.

I have ClientID (autonumber) as the unique identifier on the clients table, utilityID as the unique identifier on the utility table, and in the utility table.
I have a 1 to many relationship established between the clients and utilites table as 1 client can have many utility bills. Am I right so far?

Now at this stage I've tried entering some data into the form and it seems to have entered ok. However when I open my database again, despite saving it there's nothing there. Great.
Further to this I simply cannot get the knack of junction tables, so I've left those out as it's just leaving me pulling my hair out.

Normalisation I think I get the basic principles of, and I'm now aware that I should never really have need to enter the data for any field (e.g. name) more than once.

I've attatched my work so far, and rather than trying to make a database that indicated I know what I'm doing, I'm just trying to get something as basic as possible that does what the spreadsheet asks for.
Any feedback would be hugely appreciated, or even just an example of where I'm going wrong.

The spreadsheet makes it all look relatively simple in terms of what she wants me to make, they're effectively my guide notes for layout and required data, but putting it into practice is proving impossible and I'm running out of time to learn, having been asked to get it done by today (which is now almost certain not to happen).

Sorry for sounding as newbish and braindead as they come, but having thought I'd started to get the hang of things I'm now convinced I've got no idea and the chances of me getting what I want out of this are slim at best.
Any help really would be much appreciated, I'm not asking for someone to do all the work for me as I simply can't afford to offer payment as much as I'd like to right now, but just a couple of pointers in the right direction would be great.
I really appreciate the help so far, sorry for being a PITA!

Even if what I've done so far it crap (which I'm sure it is), as long as it works in getting data into the database and to the point where I can manipulate it to make the forms and reports indicated on the spreadsheet I'll be happy.
Aside of making a form to represent the utilities table, I'm really clueless as to what my next step is going to be.
I thought next I would do the "ISSUES" table, but what can I put in there for a unique identifier, as surely any identifier in a table like that isn't required really?

Thanks again guys, your help means a lot to me as otherwise I'd still be stuck on step1. (cue the jokes that I still am ;))
 

Attachments

oh yeah and it's now in access 2000 format I believe, done in 2k3 but it opens ok in 2000 I'm told :)
 
oh yes, and my last question for now I promise,

Is it ok not to include the ID fields on forms, or hide them (via the property settings) where they do appear? Just saves her wondering what they are and fiddling etc and me being asked questions :)
 
I for one do not have anywhere near enough free time to create a db app for you. Even if I did, only you and your gf understand your real world requirements and data model and lacking that, whatever 'we' might make may not meet your requirements.

You say you understand normalization but not junction tables...:confused:

my advice...stick with your spreadsheet and forget access since you don't appear willing to make the mental adjustment required to thinking in terms of a relational database instead of spreadsheets. Either that, or be prepared to lay down some serious money for a custom built app. A lot of db professionals charge $50+ per hour.
 
I don't know if you've solved this problem already, but I'm a student with a good knowledge of basic database issues like what you're doing. If you still want one doing, drop me a message and we could have a chat about it. Don't worry, it wouldn't be a $50 an hour jobbie!
 
£25 per hour is cheap. It should be around £250 a day (7 hrs) + expenses + bonus. That makes it around £40 per hour.

Col
 
oh yes, and my last question for now I promise,

Is it ok not to include the ID fields on forms, or hide them (via the property settings) where they do appear? Just saves her wondering what they are and fiddling etc and me being asked questions :)

not a problem- just go to properties and have visbile set to no - i do it all the time

g
 

Users who are viewing this thread

Back
Top Bottom