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
Related
I am building a new business application for my personal business which has close to ~100 transactions of sale and purchase per day. I am thinking of having Separate tables to record the sale and purchase with another linked table for Items that were sold and a seperate linked table with items that were purchased.
Example:
**SaleTable**
InvoiceNo
TotalAmt
**SaleTableDetail**
LinkedInvNo
ProductID
Quantity
Amount
etc.,
would this design be better or would it be more efficient to have one transactiontable with a column stating sale or purchase?
-From an App/Database/Query/Reporting Perspective
An invoice is not the same as a sales order. An invoice is a request for payment. A sales order is an agreement to sell products to a party at a price on a date.
A sales order is almost exactly the same as a purchase order, except you are the customer, and a sales order line item can reference a purchase order line item. You can put them in separate tables, but you should probably use Table Inheritance (CTI, extending from an abstract Order). Putting them in the same table with a "type" column is called Single Table Inheritance and is nice and simple.
Don't store totals in your operational db. You can put them in your analytic db though (warehouse).
You are starting small, thats a quick way to do. But, I am sure, very shortly you will run into differences between sale and purchase transactions, some fields will describe only a sale and some fields that will be applicable only for purchases.
In due course, you may want to keep track of modifications or a modification audit. Then you start having multiple rows for the same transaction with fields indicating obsoletion or you have to move history records to another table.
Also, consider the code-style-overhead in all your queries, you got to mention the Transaction Type as sale or purchase for simple queries.
It would be better to design your database with a model that maps business reality closest. At the highest level, everything may abstract to a "transaction", with date, amount and some kind of tag to indicate amount is paid or received against what context. That shouldn't mean we can have a table with Tag, Date, Amount, PayOrReceive to handle all the diverse transactions.
I am creating a windows forms application that must control the entry and exit of people in an office building. These people may be visitors or employees, and everybody must use an access card at the building entrance. A card will be programmed temporarily when the person is a visitor, and the employees should use their own cards. My doubt is about my database. Is there a way to do this nicely? The cards (no matter if it is an employee or visitor ) has a strong key to the ratchet can identify it wich comes from the manufacturer of turnstiles and I can't change it. So, my structure is:
In my database, I have a table where I keep the cards. When someone try to get inside the building, the turnstile sends to my system the date and time of access and the card code. Now I do not know how to separate the employees and visitors. Should I have a separated flow table to employees and visitors? For the employees flow table, I get the employees card from the card table using the same ID. In the visitor flow table, I need to know who is the visitor using the temporary card (the key to the temporary card never changes, so I can not rely on me only in the key). Or should I only have a flow table with a Visitor_ID and Worker_ID column , one of which will always be null (so I know if it was an employee or a visitor by the field with a value).
Can anyone tell me which of the two is more applicable and why?
Employees and visitors are both people. Specifically people that may (or may not) have an access card assigned to them.
I would have one People table that has a foreign key relationship to the AccessCard table. If you only care about whether the person is an employee or visitor, but the information you store is otherwise identical, a boolean column is fine. If your system stores additional information for employees and/or visitors, create an Employees and Visitors table, and have a foreign key relationship from People to each of those.
I would create single table to store both employee and visitor then add an extra column for Type(E, V).
Let's consider I have the following not normalized table
1) warehouse
id
item_id
residual
purchase cost
sale cost
Currency
I tried to normalize this and I obtained this tables:
1) warehouse table
id
product_id
residual
cost_id
2) costs table
id
purchase cost
sale cost
Currency
Does that comply with database normal forms?
Thanks much in advance!!!
This should be a comment, but it's too verbose.
There's not enough information to provide an answer - we have to infer structure from context - and the context is confusing. Your initial record looks like a description of a product to be bought and sold - but you've named it as warehouse - which is a place for storing products. I've no idea what you mean by residual. Do you have multiple purchase costs for a specific product? If so how are they differentiated. Similar for sale cost. If ther are multiple costs involved why is the selling price tied to the purchase cost?
I don't know what "residual" means in this context. But just ignoring that ...
I doubt that there's anything to be gained by breaking cost out into a separate table. Let's say we have two products, "toaster model 14" and "men's shirt style X7". Both have a cost of $12. So you create a cost record for $12, and point both records to this. Then you realize that you made a mistake and the toaster really cost $13. So you update the cost record. But that will then update the cost for the shirt also, which is almost surely wrong. Having a separate cost table would mean that you would always create a new cost record every time you created a stock record. Nothing is gained.
The fields you have listed look to me like they all belong in one table. You'd also need an item table that would have data like the description, maybe manufacturer, product specs, etc.
Your warehouse table appears to really be a stocked item table, as it lists items and not warehouses, but whatever. I suspect it also needs some sort of serial number, or how will you link a given physical item in the warehouse to the corresponding record?
If by "sale cost" you mean the price that you will charge to the customer when you sell it, I doubt this belongs in the warehouse table. When a customer buys a product, do you tell him, "I can sell you the one that's in bin 40 in the warehouse for $20 or the one that's in bin 42 for $22. Which do you want?" Probably not. I suspect you charge the same price regardless of which particular unit the customer gets. The fact that the price you have to pay to your supplier went up between when you bought the first one and when you bought the second one normally does not mean that you will charge your customer a different price. You may raise the price, but you will have one price regardless of which unit is sold. Therefore, the selling price goes in the item table, not the warehouse table. If "sale cost" is something else, maybe this whole paragraph is irrelevant.
I'm trying to make the database system point of sale, however I am confused between the entity and product inventory entity. What are the differences between product and inventory?
I know that the inventory should control the amount of product available .... but i have all that in products.
product code
name
description
cost
unit price
Subcategory code
brand code
amount available
Minimum quantity for rehearing
state
tax code
weight
amount wholesales
wholesales price
perishable
due date
creation date
upgrade date
what i should have in inventory? I have researched and according to what I read I need to have the product, the description, the quantity, purchase price, sale price, profit or gain and date of the transactions. But almost everything is in the Products table, what should I do?
A Product is an abstract Good or Service. A Good is the specification of an Asset.
Example "2014 Mazda 3" is a good. A "2014 Mazda 3 with VIN 12345" is an Asset.
A Catalog is the list of products that you want to sell. They don't need to exist yet, or you could be selling them for someone else.
Items Held For Sale are assets that you keep around to sell. These could be consigned (owned by someone else).
Inventory is an accounting concept. It is the dollar value of the items held for sale that you own, plus inbound and outbound goods that you're responsible for, plus any costs associated with holding that inventory.
You can track the value of inventory in a variety of ways such as FIFO and LIFO
I think you can store the inventory in the products table. There will certainly be transaction tables for purchases for the products and sales and even adjusting records (when items get count and the number differs from what's stored in the database), but you can easily work with the stock stored in the production table itself, thus not having to scan the whole database and sum up all purchases and sales and corrections every time (and never being able to delete old transaction data from the database, as that would invalidate the calculations).
However there are reasons to have stock stored in an inventory table instead. For instance if you want to store different statusses, e.g. you have 100 pieces in store plus twenty just arrived and still unchecked. Or you have a store with goods plus a warehouse housing additional stock. Or you have charges (different model numbers for example for a slightly altered product) which you offer as the same product, but still want to know how many old and how many new ones are in stock. And so on.
So make your mind up, if you want to store additional data with product stock, which would result in an 1:n relation instead of 1:1 which you have now.
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.