I am trying to decide which is the best way to setup the tables in a customer database.
We have customers with contacts - that bit is simple. Each of out customer has numerous sites and each site has is own contacts.
The questions are:
1. Should there be two tables for Customer sites (main site table and sub site table) or is it best practice to have all sites in a single table with a column linking subsitesID to the ID of the main site: ie
tblSites
SiteID (PK)
SiteName
MainSite (if the site is a subsite of another)
More site information fields......
2. The same question really goes for contacts. Should there be a single table for all contacts (easy if only one table for sites) or seperate tables for mainsite contacts and subsite sontact.
I guess this is really about normalisation.
I have managed to get the system I am developing to work with both methods but I would be keen to understand what is the most acceptable method.
I am about to create a system where I want to use MS Access for data and MS Outlook for email,contact management etc. I have a dilemma (what do I use for storing the contacts)? I know I can use Access and use VBA to send emails etc but I also want the user to be able use Outlook directly to send emails etc as normal using that contacts (Outlook) list. Using Office XP at the moment btw.
I would appreciate comments as to the best way forward before I start. Thanks in advance.
My problem is that I would to write a query to display the number of days taken for each of the 12 months of the year.
In the example of Employee 4 their sickness spans two different months, I can't get my head around how to produce the correct result which should look like:-
My application has 12 main tables, 8 join tables connecting the main tables, 8 tables of attributes about the main tables, 21 note/classification tables, and 1 type table. The application provides relationships between data and does _no_ updating. In order for the data to report correctly, subreports are necessary.
I wish to create one report for a Section of data. There are 3 report possibilities: 1. Report of "section" item in one table, with all connections to items in main tables; 2. Report of "section" item in one table, with all connections to items in main tables and connections to items in attribute tables and note/classification tables, omitting printing of Description fields for all tables; 3. Report of "section" item in one table, with all connections to items in main tables and connections to items in attribute tables and note/classification tables, including printing of Description fields for all tables;
My questions are as follows: 1. Should I be building the report in Access or Crystal? (I have a licence for both, but so far have used only Access). 2. Can these options be built into one report, or do I need multiple reports? I.e. I could build the report with Subreport A) including a report on a main table and Subreport B) including a report on a main table, attribute table, note and classification tables. Are there better ways to do this? 3. How do I make the Description field, printable or not, flaggable at run-time?
I was going to say before I screw it up, but that would have made the title too long.
I've read some forum history and done some searches and can't see that a similar query has come up previously - but if anyone can point me at previous relevant threads then that would be much appreciated. I've looked at some of the design theory threads, but am not really sure whether I've applied some of the good stuff in there effectively - and have put this query here as it's specific to my database rather than a 'general principles' thing.
I am hoping that some kind person/people might be able to pick holes in my planned database revamp as I may not have seen some of the pitfalls - thank you.
Background: I am the first and sole employee of a grant-making trust and set up our (still relatively small) database early on - wish I could have waited, but before my database everything was paper-based and impossible to manage. The data is all on the database, but an exponential growth in number of enquiries/applications over the last year means that it can't be easily manipulated in a way that meets our needs because of my short-sighted (OK, poor owing to inexperience in job) initial design in some areas.
Database: What it's supposed to do: In brief, the way our organisation works is that we get a phone call or a letter or sometimes an entire application from a charity or community group, decide what to do with it and have to manage the funding contract (regular reviews, grant instalments) if the application is successful.
I think existing data is reasonably normalised (certainly at least equivalent to normalisation in the structure below) so migration shouldn't be a problem, but if anyone spots any normalisation or naming convention issues then please do point them out - I'm an Access amateur, but would like to get it as right as I can (this time). Small letters indicate linked tables, numbers indicate 'footnotes'.
(a) tblProjEvent PEvID (primary key) PEvDate ProjName ProjEvent (g) ProjEvDesc - additional detail - e.g. who involved, topic if not obvious from event field. ProjEvActWho - who is responsible if future action ProjEvActDue - due date ProjEvActComp - checkbox ProjEvActCompDate ProjEvNote (NB not to duplicate description - more for 'additional notes arising from completed action' or sensitivities that may need to be considered and kept separate from regular reporting)
(b) tblOrganisation Details not listed for brevity, but split one field per line of address/detail, org name as primary key - existing table can be migrated as is (2). Includes suppliers, networking orgs. (f)
(c) tblProjSourceLup How they heard about us - list of sources for speed/consistency of data entry.
(d) tblProjStatusLup What it says on the tin - where we're at right now with a project. History/status changes recorded in tblProjAction.
(e) tblProjReasonDecline List of common reasons for speed/consistency of data entry
(f) tblOrgContacts OrgContact ID (primary key) Names/personal details of organisational contacts, split one field per item (firstname, lastname, jobtitle, etc).
(g) tblProjEventLup Letter, Funding contract, review meeting, report, telecon, Board review, etc. May be a future action.
Accounts functions: Payments in/out linked to organisation with a lookup table for account types (in, out, grant, donation, expenses etc etc). Works fine and can be migrated as is (2)
The current arrangement of relationships has the organisation as the focus - I'm looking to make the project the focus, which seems to make sense as each project is unique - whereas we may get several project applications from the same organisation - and the existing structure makes it impossible to sort these out :o.
Footnotes
1) Vast number of applications that fall into the "arrive, get read, get binned" category make this duplication worthwhile - most applications won't make it into the Project Event table. Apart from the "Greetings in the name of the Lord"/419 e-mails, they do all need recording somehow so we can spot any trends and correct misinformation - save hard-working fundraisers wasting their time*.
2) Of course data validation will be necessary, but in most tables we're talking hundreds or thousands of records only, not tens of thousands so should not be that onerous. Especially as I've been the only person using the database, so there are hopefully not too many inconsistencies!
This post is too long already, but if I've been uselessly unclear in explaining anything or anyone wants any more before they want to comment on efficacy of structure please let me know. All feedback appreciated (as I said, I work alone, so really looking for idea-bouncing to check I can see the wood as well as the trees as much as anything - thanks).
*As charity is always a sensitive area and some of you may be involved with voluntary work, an OT comment: 'No response' might seem rude - but if an organisation is -clearly- excluded by the criteria on our website, or that very same person (or a large charity who should be able to manage its information effectively) has previously been told that they are ineligible by reason of their location, size or type then they have had their response already. I could spend all day every day writing 'No' letters - I'd rather be doing something more positive with my time (like checking out/meeting with organisations that are potentially eligible so they get their answer - and in some cases money ASAP). Not R-ing TFM (aka grant guidelines) apparently applies to fundraisers as much as any other profession :rolleyes:
Part of the function of my Db is to produce quotations. I specifically need one table containing line items and will use another table (update query) which will contain the 'quoted for' items. Transfer will be based on numbers of users required. I have the basic idea in mind; i will have a form with drop down to select numbers of users and then some Vb to take records from one table to the other. I can do that fine. The bit I am struggling to structure in my mind is as follows:
In a quote there will be typically three line items
1) Software 2) Installation / Configuration 3) User Training
I can easily do as described above but that relies on the main table being pre-populated with all three line items. however, I'd prefer to have the ability to have prices for daily rates, relating to installation and training, in another table so as to be able to change/update them and not have them fixed in a table.
So I think I would want to have the three line items update query across buy somehow control the list price of the services element controlled elsewhere.
Part of the function of my Db is to produce quotations. I specifically need one table containing line items and will use another table (update query) which will contain the 'quoted for' items. Transfer will be based on numbers of users required. I have the basic idea in mind; i will have a form with drop down to select numbers of users and then some Vb to take records from one table to the other. I can do that fine. The bit I am struggling to structure in my mind is as follows:
In a quote there will be typically three line items
1) Software 2) Installation / Configuration 3) User Training
I can easily do as described above but that relies on the main table being pre-populated with all three line items. however, I'd prefer to have the ability to have prices for daily rates, relating to installation and training, in another table so as to be able to change/update them and not have them fixed in a table.
So I think I would want to have the three line items update query across buy somehow control the list price of the services element controlled elsewhere.
Last week some very altruistic folks here helped me solve a many-to-many relationships quandry, and I am hoping that there may some others out there who can help with another question.
I have a feeling this is simple, but I can't quite get my head around it, and have not been able to find it in the past forum threads, but....
I want to create a tblJobs that has information about our clients' Companies, as well as Contact. As there can be many Contacts for each Company, my current setup looks like this:
tblContacts ContactID (Pkey) Name Lookup_to_qryCompanies_to_Contact(shows Contact's company)
tblComanies CompanyID (Pkey) Company Name (Client info is included as embedded table based on qryCompanies_to_Contact)
qryCompanies_to_Contact Company (from tblCompanies) Contact (from tblContacts) (one-to-many)
In my new tblJobs, I would like to have a combo box in which I can input the company name, and then the next field will have another combo containing ONLY names of the contacts affiliated with the chosen company. (I will also eventually like to make a form that allows the same function, but am assuming that the process will be the same for updating the table trhough a form as it would be updating it directly).
I am designing a database for my organisation. I have done most of it but am stuck on this. Ideally I would like to have a check box (in a table) that when checked a load of data is carried across from that record to a record in another table.
Given that I can't and don;t want to use VB is there anyway that this can be done easily?
This only shows the flow if the main category is "Floors", sub category "Joist", and then the choices under subcategory "Joist". There will be others for the other categories, subcategories, and choices.
Can someone help me or steer me in the right direction in setting up the database table/tables to accomplish this. Oh and BTW, there will be prices attached to each "Choice" under the subcategories.
I hope that this makes sense... any help would be much appreciated.
if i had a table with products and i want to keep a record of what has been chaged or added to this product, whilst keeping the old records how could i set it up in a databse?
the excel spread sheet looks like this
product commments
1 chnged this and that 20/08 1 modifyed component 21/08
It's a simple question really. I'm currently learning databases and am doing a project, just to show that i understand everthing i've learnt so far. I have to produce a small database.
There's nothing difficult about the project, and its a very basic database, but i was just hoping to ask a small question.
I'm producing a DVD database, to hold details on a collection. My main table holds the majority of the fields, as follows;
The problem came with boxsets. Originally i was just going to have boxsets as one entry, but some contain a few dvd's, each with different certification, etc, and i wouldn't be able to record running length, director, etc. So i added a ysnBoxset field (just to record whether a dvd was part of a boxset or not) and then made a new table with
lngDVD_ID strBoxsetName
So now i can record which are part of a boxset, and the name of the boxset they belong to. But.. then i got to the problem of Purchase Price. Obviously i cannot record an individual purchase price for those which belong to a boxset, and i want to be able to record the price of the boxset.
So my question is... is it acceptable to add a curBoxsetPrice field to tblBoxsets, which would allow me to store the price... and then just leave curPurchasePrice as £0.00 for those dvd's in a boxset??? Or is there a better way of doing it? (I know there is, but i'm a novice :( )
Thanks for any help you can give, sorry for the lengthy explanation! :rolleyes:
Within my db I have a table, tblProjects which currently has 36 fields. Each project will have a fixed set of 12 tasks, each having a begin and end date as well as a yes/no "completed" field. This would add another 36 fields to tblProjects.
Instead, I have created a new table tblTasks which has these 36 fields along with a PK(TaskID) and FK(ProjectID) and is related to tblProjects. I believe tblProjects is already normalized properly with relationships to tblCompanies and tblContacts as well.
I'm not sure if this was neccessary, or should I have just added the task fields to tblProjects. What, if anything, are the advantages of one way over the other? I'll be upsizing to SQL Server, does that make a difference?
Bit of a long one but I require some advise if people can supply it.
I've started creating a DB that is now getting out of hand due to me being inexperienced. The things I want to do now are getting way to complicated. From reading various posts I know that this is all being caused by my database design and while the DB is still young I'm go back to square one. I want your advice on this if you can to ensure 3 weeks from know I'm again not chasing up weird bits of VB code to make it all work.
I basically have a lot of information to hold that interconnects with each other. I'm making up a role profile DB (so we can assign define access rights to a computer system) I have lots of info to collate but the basic stuff is.
Staff Records (Name, business area & ID) Applications (What computer applications do staff require) Shared Drives (What access to shared drives and folders do they need) Shared Mailboxes (what access to shared mailboxes) Roles (users will be assigned roles to suit their requirements)
Basically what I have at the moment is below.
Roles Role ID Role Name and about 15 other fields that dont really matter for this
Applications Application ID Application
Shared Drives Shared Drive ID Shared Drive
Shared Mailbox Mailbox ID Mailbox
Each role will only have a select number of applications, mailboxes and drives from the overall list. so role 1 may give access to 2 of the 10 applications, 1 out of 5 shared drives and 3 out of 4 mailboxes. Role 2 on the other hand may need 9 out of the 10 applications, 1 out of the 5 shared drives and 1 out of 4 of the shared mailboxes.
I just don't understand how I can create a form from these tables that would display all the different roles with their respective apps, mailboxes and drives they would need.
any advice you can give to help whould be appreciated.
I am designing a db for our Law office. I want to have tables for different types of Civil Cases-ie Divorces, Deeds, Contracts, Personal Injury, Auto Accident, Slip and Fall, Product Liability, etc. The divorce, Deeds, tables are easy but I am having difficulty deciding on the personal injury tables. Heres my dilemna. Can I get away with one or two Personal Injury tables even though there will be blank data fields. For example, I will need a field for the name of the product in a Producrs Liability field. This field will be blank in all other Personal Injury Cases. I know the rule is you don't do that but my alternative is 15-20 tables for every concievable Personal Injury Case- Auto Accidents, Slip and Falls, Fraud, Prouduct Liability, Accounting, Attorney, Dental and Medical Malpractice, etc. This is in addition to other civil case tables, criminal case tables and federal case tables. Anyone have a suggestion?
I am not sure if which I should be using as the main entity for my tables. I am creating a database for hourly information on individual employees. Each employee will have the same types of hours to keep track of (weekly, bi-weekly, monthly etc) I naturally thought to treat each employee as the databases own entity and created fields for each type of hours but hit some trouble when trying to pull queries to compare each employees hourly information against each other to see who is being efficient or not. Each employee has the same exact fields but with just different numbers. We track each type of hour by week (Field One: Week 36, Field Two: Aug 28-Sep 03)This is the first time I am creating a database from scratch. All advice greatly appreciated and TIA :confused:
I have a table within a database and i was wondering whether or not i should split the table into 2 seperate tables.
The layout of the existing table is to record quotation information ie product codes, cost price, sell price, delivery dates available etc and it also contains fields that allow the user to state if the quote has been authorised or declined, when it was authorised and a number of options to explain the reason the quote wasn't accepted.
QuotationID - Primary Key EmployeeID - Foreign Key CustomerID - Foreign Key EnquiryID - Foreign Key ProductCode Quantity CostPrice SellPrice DeliveryDateAvailable Notes Authorised - Yes/No field Type DateAuthorised Declined - Yes/No field Type ReasonDeclined LostPrice - Yes/No field Type LostStock - Yes/No field Type LostDelivery - Yes/No field Type LostCustomerClient - Yes/No field Type LostNoFeedback - Yes/No field Type
above is the layout of the table, does anyone think that it might be a good idea to split this table into two tables, one table to record the quote information and another to hold the authorisation or decline information??????
i am creating a database for a local football club. I want to show player information (the main focus of the database), such as, what guardians are responsible for this player, what are the Doctors details for this player, what team does the player play for etc. I have seperate tables for the Guardian, Doctor and Team information.
I also want to hold Staff details, (Name, address, staff title etc)
My problem is that someone in the staff table, could also be in the guardian table.
Should i combine the Guardian and Staff tables into one table as I dont want to have to enter the data twice for both a staff memger and a guardian
Note: a player can have more than one guardian a guardian can be responsible for more than one player.
What is the best way to approach the design of these database tables.
Have a database that I am working on this is constructed to perform Compliance tracking of wellness activity by employees. Have all my tables, queries and a form that has 3 tab controls as well as a subform on one of the tabs.
It is necessary to create a quarterly report card based on 6 wellness cateogories that have specific criteria. I thought I was OK but now I am having difficulty pulling it all together on the report. I now think that it has to do with my table construction and I am looking for advice. If there is someone I could send my DB to who can take a look and give advise or assistance I would greatly appreciate it. Thanks.:confused:
I'm currently in an internship working solely with databases. I've become really interested in designing databases and I now want to design my own. I was wondering if I explained my table structure then someone could give me their thoughts and ideas for improvement. I have a huge sport trading card collection and I wanted to create a database for it. This way I could run some quick queries to find out how much my collection could be worth, how many cards I have, easily keep track of duplicates. Things like that.. This might seem strange, but I think it would be a good learning experience that would help me utilize many of the features of Access.
My Table Structure:
Ok I have a Company table(Topps, UpperDeck, etc) and they sell many boxsets(which would be another table).. Boxsets have many Cards(which would be my third table)...
Now here is where I get confused. I want have a sports table that would categorize my cards by what sport they are, but I don't know where I could link this. I also have a players table. This table will have a 1:M with Cards because 1 player can have many cards, but couldn't Cards and Players have a 1:1 because 1 card shows one player???
Finally, I want a Price Table that will be linked somewhere, but I've yet to figure out where to link this too.. Have I missed anything???
Your ideas and opinions are greatly appreciated!!!
i have a table(patients) with more than 1500 records.this table contains patients information like diagnosis etc.I use cbo boxes in my form to choose info.(i have separate tables to keep this information e.g.table for diagnosis, table for treatment procedures etc.
of course these info are kept in the patients table as text fields.and also i have many query with criteria to select specific records(for example ) parameter value is [Enter diagnosis] and i type for example "cardiac" to get the list of cardiac patients etc.
now , the size has become large . so i want to do somthing to solve this i designed this when i was very new to access.
how if i want to change the field type from text to number which can look up the required info from other table.
but if i do this , i think that my queries want work .
any advice on this.
i have about ten fields to be changed from text to number.
tblreservation (cottage reservation details) cottage (text) - linked to tblCottage customer (test) - linked to tblCustomer start date (date) number of nights (number) Adults (number) Price (currency) etc..... ReservationID (autonum)
tblCottage (list of cottages available for rental) cottage (text) CottageID (autonum)
I need to add a table structure which defines the price band for each cottage at several times throughout the year, in order to take account of peak holiday periods etc. The price field in the tblReservation table needs to refer to the correct price band based on the cottage and the start date of the reservation.
Any thoughts how best to approach this would be greatly appreciated.
