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.
Related
Let's say my company is producing medical products, these products are used in many different lab testing instruments. The business logic hierarchy goes like this:
A lab has multiple locations (Up to thousands)
A location has multiple departments (Chemistry, Hematology, 3-5 per location)
A department has multiple instruments (No more than 10-20 instruments per location)
An instrument has many products.(No more than 1-5 product types per instrument)
The table structure currently mirrors the business logic, like displayed on the left. I suggested we make a small change, displayed on the right.
What are some pros and cons of each approach? I feel like the left-hand side approach might be a bit slower due to chaining so many Joins in a row.
The biggest "con" I see to the approach on the right-hand side is that you lose the association between Department and Location. For the relationships that you described atop your post, the structure on the left is correct from a design perspective.
HOWEVER...
The design that you have means that the Mass Spectrometer at your San Antonio facility will have a different ID than the one at your Denver facility. Is that intended?
------------------ revision after discussion in comments ------------------
You've described a couple of many-to-many relationships - a location will have multiple instruments and multiple locations can have the same instrument (e.g. Mass Spectrometer). To support that, you'll need cross-reference tables. Here's an initial sketch. My standard is to call the table's primary key "ID", and any field called "[table-name]_ID" is a foreign key to the corresponding table:
Lab
ID
Name
Location
ID
Lab_ID
Street_Address
City
etc.
Department
ID
Name
Location_Department -- this lists the departments at a given location
ID
Department_ID
Location_ID
Instrument -- Scale, Oscilloscope, Mass Spectrometer, etc.
ID
Name
Description
Location_Department_Instrument -- inventory at a given location
Location_Department_ID
Instrument_ID
Instrument_Serial_Number
Let me know if this makes sense.
Good afternoon. I am tasked at starting the framework (for a Final group project) at building, maintaining, and allocating a MySQL database for a proposed company. This company has many buildings, and may of them have multiple floors and many rooms. The database should store all the buildings, their GPS location, their number of floors, the floor plan images corresponding to that, all their rooms, and their locations within the building.
At the moment, I have a database with one table, "Buildings". In "Buildings" I have rows for the following: ID, Name, Latitude, Longitude, # of Floors, Floor plan Image(x4). I am assuming that there are a max of four floors. [probably a bad idea]
I am now stuck with how I want to store all the rooms, the floor plans, and the rooms location within the floor plan.
My initial thought was to create a new table for each building, and have rows for Room Number, Corresponding Floor Plan, and Location (Lat/Long). Yet if the company has, say, over 100 buildings, and each building has maybe only one floor and a couple rooms, then I think this would be overkill. Plus I think dealing with 100's of tables is bad practice.
Is there an easier way with dealing with lots of buildings, but with varying room amounts and floors?
Any suggestions would be much appreciated!
Each entity should have its own table. The tables will be linked using Primary Keys and Foreign Keys. Number of floors should not be hard-coded, you should retrieve the number of floors using the COUNT function.
Normalize your database up to 3NF.
Here is what your DB should look like:
Buildings:
BuildingID(PK)
LongName
ShortName
Latitude
Longitude
etc
Floors:
FloorID(PK)
BuildingID(FK)
FloorName
etc
FloorPlans:
FloorPlanID(PK)
FloorID(FK)
FloorPlanName
FloorPlanImage
Rooms:
RoomID(PK)
FloorID(FK)
RoomNumber
Latitude
Longitude
RoomSize
etc
New to database design and admittedly over my head. Trying to create a small database that will allow me to find state highway construction project information along any given road. Relationships include:
One contract number to one project; One county to many projects; One road to many projects; One road to many counties and one county to many roads; One manager to many projects; One contractor to many projects; One contact list (phone, email) to one manager; One date each (bid, start, complete) to many projects.
Would be a small database, maybe 500 records total. There are only 6 counties. Right now I've broken roads down into 6 separate "roads by county" tables so while the route number may be the same in different counties each record will be unique because it's in a separate county table. Is this OK or is it better to keep one roads table and assign county values there? I created other tables listing the counties, contracts, contractors, managers, dates and project description. Just don't know what to do with them.
My purpose is to be able to search, mostly by road number and keyword, to find what projects are on what road at any given time. I'd also like to update this info via forms. The data will change frequently and it's just a little too unruly for a spreadsheet. I simply can't wrap my head around how to setup and relate the tables and individual records. Any thoughts would be phenomenally appreciated.
I imagine a database with a simple structure.
The relations many-to-many normally should and can be avoided.
Access doesn't have a direct implementation of this relations. You need to create a cross table between the two main tables.
Anyway I created a database for projects more complex than this so I tried to accomplish your request.
The "core" table is tblProjects that refers for details to other tables.
Since projects are related to roads, I use road as the main item and a road can have a list of counties. If you want to know how many projects are in a county it can be simply done with a query looking for all the roads that have that County_ID.
If you want to look up for project for one road, simply find the road_ID (e.g. using a combo-box to select it) and you can filter (query) the tblProjects by Road_ID.
tblManagers
*IDManager
LastName
FirstName
eMail
Phone
Mobile
tblContractors
*IDContractor
ContractorName
Reference
tblCounties
*IDCounty
CountyName
Road_ID
tblRoads
*IDRoad
RoadNum
RoadName
tblProjects
*IDProject
ContractNum
ProjectName
StartDate
EndDate
BidDate
Contractor_ID
Road_ID
Manager_ID
The fields with * are the Key Fields. They are in relations with the _ID corresponding fields (check referential integrity and cascade deletion when you create the relation).
Let me know
I need help about how to model a database. I need to store the timetable for each transport public line. Lets see what we have...
I have different lines (bus number 100, 101, 102 and so on).
Each line has different stops and I need to store the coordinates of each one of them.
Each stop has a specific timetable, for example:
http://rozklady.mpk.krakow.pl/aktualne/0106/0106t001.htm
http://rozklady.mpk.krakow.pl/aktualne/0106/0106t003.htm
The aim of the program that I'm developing is to check for errors in the official timetables. Each bus has a tracking GPS device that sends its position to a database every 10 seconds. So I must check the hour of the reports whose coordinates are close to the coordinates of one of the stops and compare that time with the official time, and in case there is a big difference, create a row in other table STATISTICS reporting the issue.
Anyway, this was just for the context. The truth is that I don't have any clue about how to store it in an efficient way.
I thought about creating a table with the Stops: STOP_ID (PK) - NAME - LAT - LON - LINE - TIMETABLE
Where timetable would be an array containing all the times serialized for that stop [5:03,5:25,5:50,6:12,...].
Although I think this is not a good solution, I can't think about a better approach.
Maybe I could create a table for the stops, and other for timetables, but what would be the columns for timetables? I have so many variables... if it's weekly, saturday or holiday, a lot of hours, minutes... and all different for each stop.
Could you share any thoughts about how to face this problem? Thank you very much!!
As Simon mentioned, you are starting a big project.
Suggestion: Read up on the various normal forms for relational DBMSs; this will give you some helpful background if you don't have it.
What are your entities (tables)?
Bus lines (consider the outbound trip and return trip to be two different lines).
Stations on those lines, ordered.
Trips (e.g. 106 bus leaves central station at 05:22, another trip at 05:42, etc).
Scheduled-stops
GPS observations.
Here are possible tables and columns:
Busline table: one row for each busline.
Busline e.g. 106-outbound or 108-inbound (pk)
Description
Station table: one row for each bus stop, including ends of trips
Busline part of pk, fk to Busline e.g. 106
Stationid part of pk kf to Station
Description e.g. Second Avenue Eastbound at Houston Street
lat
long
Trip table: One row for each bus trip.
Tripid pk
Busline fk to Busline
Description e.g. 05:22 trip Central Station to University Park
Schedule table: one row for each scheduled time for each trip at each stop
Scheduleid pk ... ascending serial number.
Busline fk to Station
Stationid fk to Station
Tripid fk to Trip
Time
Observation table a row for each of your GPS readings
Observationid pk ... ascending serial number
Busline if you know it fk to Busline
Tripid if you have it fk to Trip
Time
Lat
Long
My advice with RDBMS design is to avoid serializing multiple items of data into single DBMS columns. That's why I have suggested the Schedule table.
Once you figure out how to load your Busline, Station, Trip, and Schedule tables, and you've loaded your observations into the Observation table, it will be an interesting exercise to correlate your observations with your schedules.
Be careful! You may embarrass your municipal transport department! :-)
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).