I'm working on my final project for an intro to Access DB class. My assignment is a general "Create a DB with at least 3 tables, of which 2 are linked," with some specific requirements for types of tables (customer relations, financial management, product/service-related data).
I decided to create a database for a fictional airline. I need to track financial information, particularly the sale of tickets. I have a tblFlights table that includes a BaseFare field, a tblAirports table that includes airport fees and airport taxes and a tblInvoice table that currently only has invoice number and customer ID fields in it. I suppose that I would use a report to generate an actual invoice, not a table, right? So, I don't want to store a bunch of financial data in an invoice table, and maybe I shouldn't even have an invoice table? How do I keep track of how much money customers owe and how much they have paid?
I suppose that I would use a report to generate an actual invoice, not a table, right?
Yes, use a report.
So, I don't want to store a bunch of financial data in an invoice table, and maybe I shouldn't even have an invoice table? How do I keep track of how much money customers owe and how much they have paid?
Well, I suppose some industries might be able to get an airline to send them in invoice, but I've never heard of that myself. In my experience, you pay first, then they give you the ticket. So I'd expect a table of tickets, which would identify the flight, the seat (or its equivalent), the person's name, and something to indicate that it's paid (a Boolean flag, a price, something like that).
Related
EDIT comments pointed out my question was too broad so I have done my best to focus it.
Trying to build a finance tracker in MS Access 2016 for spending analysis. I want to bring together multiple records from various bank accounts each one having a respective table that is identical to the bank statements (for ease of correcting). So lets say I have Bank1-T and Bank2-T. All bank account tables will have identical fields.
However I would also like to have the ability to, on occasion (where needed), replace certain records with subtotals to increase spending tracking granularity.
For example say I went to the gas station and paid for petrol as well
as lunch in the same payment, I would like Bank1-T to
have the single entry for payment to the petrol station, but to have
Accounts-T have the separate entries for payment of petrol and food.
Since I don't want to edit the bank account tables, I though I'd go ahead and store the split subtotals for payments in a table PayDetails-T. As there would only be a few payments I would store in PayDetails-T, how would I go about setting up a Query that brings together the payments from the various bank tables, and replaces the specific payment records from the bank tables with the ones in PayDetails-T? Can it be done in a single Query or would multiple be needed?
I looked over some of the other answers here and they did not answer the question I have.
How would I go about this problem. If an invoice is created with the following database schema:
id
customer_id
invoice_date
status
the invoice is created, paid etc. If the customer information changes, the invoice information will change since its a FK. How would I create the invoice table to record customers information at that give moment in time, so if the customer change their address in the future for example the past invoices will stay the same with the previous address.
Just wanted to see if it makes sense to copy customer information into the invoice table with their address etc. but then it will adhere to normalizing the database.
Please let me know what your thoughts are in regards to this challenge. Invoices in one example, this can also apply to Purchase orders that were created in the past should have definite information that was recorded in the past no matter what has changed now.
There are different considerations for an order management system or a reporting system.
Within an application, data duplication may prove cumbersome at volume. Will prove cumbersome at high enough volume. So you'll want to be as normalized as possible in that environment.
For reporting and history, though, it would be preferable (maybe mandatory depending on your industry and locale) to have the address info for each invoice.
It would be better to have an address table that joins to your customer table. The addresses would each have their own id field, and then you could just reference that id in the invoice table, too. Probably both the billing address and the shipping address if they're both in play in your business model.
If you don't have the flexibility to introduce a stand alone address table, then copying the address information over to the invoice table becomes a necessary evil. But dead useful information to have.
I'm a bit of a newbie with databases and database design, but I'm hoping someone can point me in the right direction. I currently have 14 monthly loan extracts, each of which contain all accounts, their status, balance and customer contact info as-of month end. Not knowing what to do, I imported each of the monthly files into Access with each table acting more like a tab from an Excel workbook. Laugh away - I now know that's not how it's supposed to work.
I've done my homework and I understand how to split up part of my data into Customer and Account tables, but what do I do with the account balances? My thought is to create a Balances table, create a relationship to the Accounts table and create columns for each month. This seems logical, but is it the best way?
99% of my analysis involves trend reporting and other ad hoc tasks - tracking the total balances by product type over time given other criteria, such as credit score or age. My intended use is to create queries to select the data I need and connect to it via Get & Transform in Excel for final manipulation and report writing.
This also begs the question "how normalized should my new database be?" Each monthly extract is cumulative, so a good 75% of my data is redundant contact info already, but how normalized should I go?
Sorry for ranting,but if anyone has any experience in setting up their own historical database or could point me in a direction that will get me on track, I would appreciate it.
Best practice for transactional systems is close to what you expect:
1. Create a Customer table
2. Create an Account table
3. Create an Account Balance table
4. Create relationships from the Account to Customer, and from the Account Balance to the Account table.
You can create a column for each month, provided you have Year as part of the key of the Account Balance table. Even better would be to have the key for the Account Balance be Account ID and Date.
However, since you are performing analytics over the data, a de-normalized approach is not only acceptable -- it is preferable. So yes, you can (and perhaps should, based upon your use cases) put all the data into one big flat table and then compile your analytics.
I'm trying to wrap my head around the proper way to design tables for a billing policy where the customer can pay for each delivery as they are completed, or they can receive a monthly invoice with the entire balance due. This is a small bit of what I have already...
I'm not sure where to go... should I create a table for paid in full and monthly statement and relate them to the invoice table... or should I relate those to the payment table... or am I all over the place....
It's a lot more complicated than you think. You also have to account for partial payments, overpayments, payments on account, refunds and other real world complications.
The only way to approach this which will actually reflect the ugliness of the real world is to treat individual charges as one thing (your deliveries), summary documents (monthly invoice/statement) as another thing, and payments/refunds as another thing.
From there you need to join these three separate things together with relationships. The temptation is to join monthly invoices to payments, directly, but that would be a mistake. At least, it would make your life more complicated than it needs to be.
The relationship between charges and invoices is relatively easy. If your customer gets a monthly invoice, then all their packages from that month point at that invoice. This makes a many to one relationship from Package to Invoice.
The more complex part is the relationship between payments and charges. For this you need a new table Payment_Application which is a many-to-many intersection between charges (Packages) and Payments. This intersection entity will also have the amount of money paid for each package. This is important because you can record here whether the amount paid was too much, too little or the correct amount.
If you want to get more sophisticated, you could normalize the payment information so that you have a payment header and detail. This lets you keep information about a payment you receive separate from information about how you choose to apply that payment.
Consider the following:
Here you have an (optional) invoice header and an invoice detail (Package) as well as a payment header and an (optional) payment detail, which may or may not relate to an invoice detail. An arrangement like this will cover the various ugly things that happen when you need to track the exchange stuff for money.
So for a project, I have to create a database and attempt to optimize as much as possible. We are given text files with data listed and I'm having trouble figuring out how I can best relate these pieces.
For right now, I have a Persons data file with names, addresses, etc. and an Airport Data File with airport coordinates, address, etc. In the Airport data file, one of the values we are given is described as this:
PassengerFacilityFee - Fees charged by the airport per passenger per arrival.
Should I create a seperate table for the fees and then use foreign keys from Persons and Airport, or how else could I organize this?
Should I create a seperate table for the fees and then use foreign keys from Persons and Airport, or how else could I organize this?
No. The facility fee is purely a property of an airport. It is not related to specific people - there is not a different facility fee depending on whether Alice or Bob flies out of LAX, for instance. The fact that the fee is assessed "per passenger" is irrelevant here.
This fee should most likely be a column in your table of airport data.