City
----
CityID
CityName
PRIMARY KEY (CityID)
Hotel
-----
HotelID
HotelName
CityID
PRIMARY KEY (HotelID)
FOREIGN KEY (CityID)
REFERENCES City (CityID)
Package
-------
PackageID
PackageName
CityID
PRIMARY KEY (PackageID)
UNIQUE KEY (PackageName)
FOREIGN KEY (CityID)
REFERENCES City (CityID)
Package versions:
PackageVersion
--------------
PackageID
VersionNumber
PackageType
PRIMARY KEY (PackageID, VersionNumber)
UNIQUE KEY (PackageID, VersionNumber, PackageType)
FOREIGN KEY (PackageID)
REFERENCES Package (PackageID)
and subtypes (of versions):
LandPackageVersion
------------------
PackageID
VersionNumber
PackageType DEFAULT 'L'
PRIMARY KEY (PackageID, VersionNumber, PackageType)
FOREIGN KEY (PackageID, VersionNumber, PackageType)
REFERENCES PackageVersion (PackageID, VersionNumber, PackageType)
FlightPackageVersion
------------------
PackageID
VersionNumber
PackageType DEFAULT 'F'
OriginID
PRIMARY KEY (PackageID, VersionNumber, PackageType)
FOREIGN KEY (PackageID, VersionNumber, PackageType)
REFERENCES PackageVersion (PackageID, VersionNumber, PackageType)
FOREIGN KEY (OriginID)
REFERENCES City (CityID)
and default Package Version:
PackageDefaultVersion
--------------
PackageID
VersionNumber
PackageType
PRIMARY KEY (PackageID)
FOREIGN KEY (PackageID, VersionNumber, PackageType)
REFERENCES PackageVersion (PackageID, VersionNumber, PackageType)
From what I can understand, apart from a Customer table, you'll need three tables:
- Contract — holding the single-valued data about a contract, excluding receipts. It might record the latest receipt number for the contract, but that would be an optimization, storing derivable data. Primary Key: Contract Number (aka Lot Number).
- Contract Items — holding the 1-6 items for the contract. Primary Key: Lot Number, Lot Sequence Number. Lot Number is a Foreign Key reference to Contract.
- Receipts — holding information about receipts. Primary Key: Receipt Number. Foreign Key: Contract Number reference to Contract again.
A given receipt is associated with one contract; a single contract may have multiple receipts over time if it is a pawn contract (buy and sell contracts will have a single receipt).
Even if a new receipt is not issued when a pawn contract is cancelled, there'll need to be a database update of the contract or the receipt (or both) to indicate that the contract is cancelled.
Is there anything that I'm missing here?
Best Answer
Consider the "bill" itself as an entity that has associated entities (activities and items). Something like this:
Customers, Items and Activities should all be separate entities, and you should include a separate entity for Sales (Bills) and Sales Line Items (Activities and Items part of the Bill). This way you can define Items and Activities once and include multiple (or no) Items and Activities on a single Sale entity record. Example below.
Setup:
Test Data:
Query:
Results: