I've designed a database structure where data is collected about cars over a period of time, for research purposes. The owner of the car enters a large amount of related data each month about the car, it's performance etc. However, I now have to handle situations where ownership of the car is transferred (possibly more than once), and I'm wondering what the best way to handle this in the database would be.
If a car is transferred, the previous owner should no longer be able to add data about the car, however they should still be able to view the data they entered up until the date of the transfer. The new owner will be able to enter data about the car from the date of the transfer onwards. For research purposes, I need to be able to join the data between these transferred car records and consolidate them into one set of data.
Currently, each car record in the db belongs to an owner via a foreign key in the Cars table. What I'm thinking about at the moment, is to create a recursive parent/child relationship between car records, where one car record may belong to another car record (e.g car_id as a foreign key in Car table). Where a car record belongs to another car record, this indicates a transfer. This allows me to preserve each car record's set of data (specific to its owner), while also chaining together the related car records. In addition to this, I'm thinking about adding a Car_transfer table, to record extra data about the transfer (probably just the date actually, as the previous and new owners will be evident from the owner_ids in the Car table) - adding a date_transferred column in the Car record would likely be largely redundant for most records, so i'm unsure if this data alone merits a new relationship table.
Anyway, i hope this makes sense! I've been going round in circles trying to find a sensible solution - any advice would be greatly appreciated!
You don't need recursive parent/child here, but just Many-To-Many relationship:
Basically you need links table [cars-owners]:
car_id, owner_id, ownership_date
So you will have data in it:
---------------
1, 2, 2009-01-01
1, 3, 2010-05-01
...
The same car owned by two people with different dates.
I would add a car ownership table. The recursive design isn't too intuitive.
Related
I am sketching up a database design and it is giving me some troubles. Basically something just "smells" about this design but I can't seem to arrive at a better way to do it. For example, the Joins needed to get back to Person table could be ugly.
Business rules
A Person can go on many Trips.
Each Trip has many Destinations for its many participants (Person).
Every potential participant has an option to RSVP for a given Trip. If they RSVP for a Trip they must then RSVP for each Destination on that Trip.
Each Destination has an optional agenda (DestinationComponent) that each participant can RSVP for.
Assume that each RSVP relationship (at every level) will "contain many more data columns" required for information about the particular RSVP - for example, each participant can Vote on each Destination and DestinationComponent (Vote column has been omitted in RSVP tables within diagram).
Current diagram
This is the diagram I have created so far:
Questions
Is there a better way to manage these relationships?
A "master 'junction' table" for RSVPs and one for votes?
I'm worried those tables would result in becoming massive overtime. Guidance would very much be appreciated!
I'm creating this little Access DB, for the HR department to store all data related to all the training sessions that the company organizes for all the employees.
So, I have a Training Session table with information like date, subject, place, observations, trainer, etc, and the unique ID number.
Then there's the Personnel table, with employer ID (which is also the unique table number), names and working department.
So, after that I need another table that keeps a record of all the attendants of each training session. And here's the question, should I use a table for that in the first place? Does it have to be one table for each training session to store the attendants?
I've used excel for quite some time now, but I'm very new to Access and databases (even small ones like this). Any information will be highly appreciated.
Thanks in advance!
It should be one table for persons, one table for trainings, and one for participation/attendance, to minimize (or best: avoid) repetition. Your tables should use primary and foreign keys, so that there are one-to-many relationships between trainings and attendances as well as people and attendances (the attendances table would then have a column referring to the person who attended, and another column referring to the training session).
Google "database normalization" for more detail and variations of that principle (https://en.wikipedia.org/wiki/Database_normalization).
I have to design tables in 0NF for my project, I am required to design the tables in 0NF form first then proceed to normalization and then draw the ERD. However it has been a real challenge for me to obtain the 0NF forms of my tables, lots of time has been wasted trying to redesign so I thought of asking help from people who might be more experienced in database design.
My database is of a Car Rental System. The system should keep records of customers,cars,employees, details of each rental and also the company is supposed to have multiple branches at different locations and each branch must have their own set of unique(identified by their license plate number) cars available.
One customer can have multiple rental records(i.e. made a rental in January then another in March .e.t.c) but one rental record is related to only one customer
A customer can book multiple cars in a single rental
Each rental is made through a single booking agent(an employee)
Employees is divided between Managers and booking agents. Each branch has a single manager but multiple booking agents.
Each branch has multiple cars located there but each car can be located at a single branch
So far, I've come up with these 0NF tables, they don't look correct to me though:
Cars(CarID,LicensePlateNo,Make,Model,Year,Color,mileage,Capacity,seats,Availability, Rate, BranchID,BranchLocation)
Customer(CustomerID, FirstName,LastName, Address ,ContactNo,Gender,DOB,NIC,RentalID,DateRented,RentalCost)
Agent(AgentID,FirstName,LastName,Address,ContactNo,Gender,DOB,NIC,MonthlyRentals,Salary,ManagerID,ManagerName,MangerLastName,ManagerAddress,ManagerContact,BranchID,BranchLocation)
Rental(RentalID,DateRented,Duration,RentalCost,Discount,AgentID,CarID,LicensePlateNo,Make,Model)
Branch(BranchID,BranchName,BranchLocation,ContactNumber,ManagerID)
I have replaced the Agent table with the Employee table and I have added 2 new columns (Position and Manager) to it. I believe the position column should store either 'Agent' or 'Manager'. If employee is an Agent, the Manager field should contain the ID of his/her Manager (EmployeeID). If employee is Manager, most probably the Manager column should be left NULL. I have also removed all other columns which were being repeated(Example BranchLocation in cars table etc...)
Cars(CarID,LicensePlateNo,Make,Model,Year,Color,Mileage,Capacity,Seats,Availability, Rate, BranchID)
Customer(CustomerID, FirstName,LastName,Address,ContactNo,Gender,DOB,NIC,RentalID)
Rental(RentalID,DateRented,Duration,RentalCost,Discount,EmployeeID,CarID)
Branch(BranchID,BranchName,BranchLocation,ContactNumber,EmployeeID)
Employee(EmployeeID,FirstName,LastName,Address,ContactNo,Gender,DOB,NIC,MonthlyRentals,Salary,BranchID,Position,Manager)
Thanks
I try to design database which contains data about street parking. Parking have gps coordinates, time restriction by day, day of week rules (some days are permitted, other restricted), free or paid status. In the end, I need to do some queries that can specify parking by criteria.
For first overdraw I try to do something like this:
Pakring
-------
parkingId
Lat
Long
Days (1234567)
Time -- already here comes trouble
But it`s not normalized and quickly overflow database. How to design data in the best way?
Update For now I have two approaches
The first one is:
I try to use restrictions tables with many-to-many links.(This is example for days and months). But queries will be complicated and I don`t now how to link time with day.
The second approach is:
Using one restricted table with Type field, that will have priority. But this solution also not normalized.
Just to be clear what data I have.
PakingId Coords String Description(NO PARKING11:30AM TO 1PM THURS)
And I want to show user where he can find street parking by area, time and day.
Thanks to all for your help and time.
This seems like a difficult task. Just a few thoughts.
Are you only concerned with street parking? Parking houses have multiple floors so GPS coordinates won't work unless you stay on the streets.
What is the accuracy of the coordinates? Would it be easier to identify each parking space individually by some other standard. Like unique identifiers of the painted parking squares. (But what happens if people don't park into squares? Or the GPS coordinates accuraycy fails/is not exact enough because of illegal parking? Do you intend to keep records of the parking tickets too?)
Some thought for the tables or information you need to take into account:
time: opening hours, days
price: maybe a different price for different time intervals?
exceptions: holidays, maintenance (maybe not so important, you could just make parking space status active/inactive)
parking slot: id (GPS/random id), status
Three or four tables above could be linked by an intermediate table which reveals the properties of a parking space for every possible parking time (like a prototype for all possible combinations). That information could be linked into another table where you keep records of a actual parking events (so you can for example keep records of people who have or have not paid their bills if you need to).
There are lots of stuff that affect your implementation so you really need to list all the rules of the parking space (and event?). Database structure can be done (and redone) later after you have an understanding of the properties of the events you need to keep records of. And thats the key to everything: understanding what you need to do so you can design and create the implementation. If the implementation (application) doesn't work change the implementation. If the design is faulty redesign. If you don't undestand the whole process (what you really need), everything you do is bound to fail. (Unless you are incredibly lucky but I wouldn't count on luck...)
Try using two tables with an intersection entity between them.
Table parking will have parking_id, lat and long columns. Table Restrictions will have all the type of restrictions that you have in your scenario with something like restriction_id, restriction_day, restriction_time and restriction_status and maybe restriction_type.
Then you can link the two tables with foreign key constraints in the intersection entity.
Example parking_id has restriction_id.
This way a parking can have more than one restriction and a restriction can be applied to more than one parking.
As you seem to have heard of normalization, and following the comment from Damien, you should use different tables to represent different things.
You should then think about how to link those tables together, and in the process define the type of relationship between the 2. Could be one-to-one (this one is the one where you could be tempted to put everything in the same table, but a simple foreign key in a linked table is cleaner), one-to-many (this is where the trouble would begin if you put everything in one table, cause now there will be several lines in the linked table with the same foreign key, and if everything was in the same table, you'd have to myltiply the fields in that table), or many to many (where you would need to add a table only to make the link between 2 other tables, thus with 2 foreign key fields pointing to records in both tables).
For example, in your case, a Parking table could hold the parking name, coordinates, etc.
A second table TimeTable could hold the opening days/time for each parking, with a foreign key to the parkingId (making it a one-to-many rlationship, 1 parking can have many opening frames). The fields of this table could for example be DayOfWeek (number indicating the day), openingTime, closingTime. This would allow you to define several timeframes on the same day, or a single one (if it's always open for example), giving in this case 7 records in this table for this parking (=> one-to-many relationship).
You could then imagine a 3rd table Price where you put data concerning the price of that parking (probably a one-to-many too, with records for hourly rates/long stay/..., and so on depending on the needs and the different "objects" you would need to represent.
Please note these are only rough examples. Database design can sometimes be very tricky and that's a matter I'm not specialist in, but I think these advises can help you go further and come back with another question if you get stuck.
Good luck !
I would like to establish a many-to-many relationship with a constraint that only one or no entity from each side of the relationship can be linked at any one time.
A good analogy to the problem is cars and parking garage spaces. There are many cars and many spaces. A space can contain one car or be empty; a car can only be in one space at a time, or no space (not parked).
We have a Cars table and a Spaces table (and possibly a linking table). Each row in the cars table represents a unique instance of a car (with license, owner, model, etc.) and each row in the Spaces table represents a unique parking space (with address of garage floor level, row and number). What is the best way to link these tables in the database and enforce the constraint describe above?
(I am using C#, NHibernate and Oracle.)
If you're not worried about history - ie only worried about "now", do this:
create table parking (
car_id references car,
space_id references space,
unique car_id,
unique space_id
);
By making both car and space references unique, you restrict each side to a maximum of one link - ie a car can be parked in at most one space, and a space can has at most one car parked in it.
in any relational database, many to many relationships must have a join table to represent the combinations. As provided in the answer (but without much of the theoretical background), you cannot represent a many to many relationship without having a table in the middle to store all the combinations.
It was also mentioned in the solution that it only solves your problem if you don't need history. Trust me when I tell you that real world applications almost always need to represent historical data. There are many ways to do this, but a simple method might be to create what's called a ternary relationship with an additional table. You could, in theory, create a "time" table that also links its primary key (say a distinct timestamp) with the inherited keys of the other two source tables. this would enable you to prevent errors where two cars are located in the same parking spot during the same time. using a time table can allow you the ability to re-use the same time data for multiple parking spots using a simple integer id.
So, your data tables might look like so
table car
car_id (integers/numbers are fastest to index)
...
table parking-space
space_id
location
table timeslot
time_id integer
begin_datetime (don't use seconds unless you must!)
end_time (don't use seconds unless you must!)
now, here's where it gets fun. You add the middle table with a composite primary key that is made up of car.car_id + parking_space.space_id + time_id. There are other things you could add to optimize here, but you get the idea, I hope.
table reservation
car_id PK
parking_space_id PK
time_id PK (it's an integer - just try to keep it as highly granular as possible - 30 minute increments or something - if you allow this to include seconds / milliseconds /etc the advantages are cancelled out because you can't re-use the same value from the time table)
(this would also be the place to store variable rates, discounts, etc distinct to this particular account, reservation, etc).
now, you can reduce the amount of data because you aren't replicating the timestamp in the join table (reservation). By using an integer, you can re-use that timeslot for multiple parking spaces, but you could also apply a constraint preventing two cars from renting that given spot for the same "timeslot" for a given day / timeframe. This would also make it easier to store some history about the customers - who knows, you might want to see reports on customers who rent more often and offer them discounts or something.
By using the ternary relationship model, you are making each spot unique to a given timeslot (perhaps with some added validation rules), so the system can only store one car in one parking spot for one given time period.
By using integers as keys instead of timestamps, you are assured that the database won't need to do any heavy lifting to index the keys and sort / query against. This is a common practice in data warehousing / OLAP reporting when you have massive datasets and you need efficiency. I think it applies here as well.
create a third table.
parking
--------
car_id
space_id
start_dt
end_dt
for the constraint, i guess the problem with your situation is that you need to check a complex rule against the intersection table itself. if you try this in a trigger, it will report a mutation.
one way to avoid this would be to replicate the table, and query against this replication for the constraint.