So far I have the following tables:
Hotel (ID(pk), NoOfRooms, Phone, Address)
Room (No(pk), HotelID(pk), Rate, Size, Occupied, Loc)
Customer (Num(pk), SSN, Name, CreditCard, Address, StartDate, EndDate, AmtOwing, RoomNo(fk))
CareTaker (ID(pk), HotelID(fk), Name, Address, Phone, Email, Salary)
Manager (ID(pk), HotelID(fk), Name, Address, Phone, Email, Salary)
With the following assumptions:
Each manager can manage more than one hotel but a hotel may have only one manager
Each customer can only stay at one hotel and be given one room
Each caretaker works at only one hotel but a hotel may have many caretakers
Rooms in a particular hotel are unique but may not be unique across several branches of the hotels
Based upon the above assumptions I think there should be the following changes to the tables
Hotel (ID(pk), NoOfRooms, Phone, Address)
Room (No(pk), HotelID(pk), Rate, Size, Occupied, Loc)
Customer (Num(pk), Name, StartDate, EndDate, RoomNo(fk), SSN(fk))
CustomerPaymentInfo (SSN(pk), CreditCard, Address, AmtOwing)
CareTaker (ID(pk), HotelID(fk))
Manager (ID(pk), HotelID(fk))
Employee (ID(pk), Name, Address, Phone, Email, Salary)
Let me know what you think and if you have any suggestions.
Each manager can manage more than one hotel but a hotel may have only one Manager
=> So you need a manager per hotel, not one hotel per manager
Hotel (ID(pk), ManagerID(fk), NoOfRooms, Phone, Address)
Manager (ID(pk), REMOVE THIS: HotelID(fk), Name, Address, Phone, Email, Salary)
Rooms in a particular hotel are unique but may not be unique across several branches of the hotels
=> okay
Room (No(pk), HotelID(pk), Rate, Size, Occupied, Loc)
Each customer can only stay at one hotel and be given one room
=> A room is identified by room number plus Hotel:
Customer (Num(pk), SSN, Name, CreditCard, Address, StartDate, EndDate, AmtOwing, RoomNo(fk), HotelID(fk))
Each caretaker works at only one hotel but a hotel may have many caretakers
=> okay
CareTaker (ID(pk), HotelID(fk), Name, Address, Phone, Email, Salary)
Related
Analyze the scenario for a retail store and identify minimum three different objects from the following
customer_name,
customer,
item_id,
description,
bill_amount,
price_per_unit,
item,
pays_bill,
purchases,
employee,
designation
I have tried item_id, bill_amount and designation as they are unique but the answer was wrong.
I also tried a lot of different options for quite a lot of time but did not succeed.
The objects are instances of a class for example employee, customer, item and purchase. In the case of customer, you may have a class name Customer which has it's specified attributes such as customer_name, ``customer_id` etc.
And when you are ready to create a new customer, you will create an object name customer or customer1 which would be instances of the class Customer.
objects are employee, customer, item and purchase.
customer
customer_name,
customer,
item
item_id,
description,
price_per_unit,
item,
purchase
pays_bill,
purchases,
bill_amount,
employee
employee,
designation
Main objects are employee, customer, item and "purchase" contains new fields with the combination of first 3 objects
The correct answer is Customer, Item, Employee
I am building a ecommerce application with two different types of users, users who shop and vendors/brands.
Should I make two tables for each user like?
User| id, email, password, username, address, stripeCustomerId
Brands| id, email, password, username/brandName, shippingRate, address, stripeAccessToken etc.
Or should I make it like so:
Users| id, email, password, username, address, stripeCustomerId
Brands| userid, etc...
This is an example of trying to model the object-oriented notion of inheritance in a relational database. If you search for that term, you'll find several answers on Stack Overflow.
In your case, I think you have 3 logical entities:
User: email, password, username, address...
Customer (is a type of user): StripeID
Vendor (is a type of user): shipping rate, stripe token
How you model those logical entities to physical objects in your database is mostly a question of trade-offs - the other answers explain those.
I assume there will be significant differences in both the behaviour and attributes between "customer" and "vendor".
I also assume your data model will evolve over time - for instance, you probably need to store more than one address for each user (shipping, billing), you probably have different lifecycles for "customers" (new, registered, registration confirmed, payment confirmed) and "vendors" (new, approved, rejected).
If those things are true, I'd just bite the bullet and have 2 tables, customer and vendor. This means you can evolve their behaviour more easily - you don't have to worry about needing a slightly different address logic between two "customer" and "vendor", you just build what you need. Your schema is a little more self-explanatory - your foreign keys go to tables that say what they do (products -> vendors, not products -> users).
It shouldn't be two tables, but three :D
1. users (id, name, password, )
2. customers (user_id, customer_specific_fields)
3. vendors (user_id, vendor_specific_fields)
As the title states. I have read many articles trying to wrap my head around this, but am still not sure if I am doing it right or not. I think I am getting the hang of it, but wanted to get some more opinions in case I do need to correct what I am doing. Example is below.
Thanks!
1NF Employee_ID,Last Name, First Name, Street, City, Zip, D.O.B., Age, Degree required
2NF Employee_ID, Last Name, First Name, D.O.B, Age, Degrees Recieved
Location_ID, street, city, zip
3NF Employee_ID, Last Name, First Name, Age
Birth date, D.O.B.
Location_ID Street
Zip Code, City
Summarised:
2NF is when every non-key attribute depends on the whole primary key. So imagine a CD. The CD has an ID number, which is the primary key. The name, artist and gender of the artist are dependent on the primary key. So this is correct:
Table_CD:
CD_ID: Name: Artist: Artist_Gender:
1 CD1 Artist1 Male
2 CD2 Artist1 Male
3 CD3 Artist2 Female
This is correct for 2NF because artist is dependent on the Key (CD_ID). We dont check for transitive dependency.
In 3NF you simply say there can be no dependencies on something that is not the key. The gender of the artist depends on the artist. Not on the CD_ID, which is the key. Therefore it is not 3NF.
To make it 3NF you must seperate out the transitive dependency. Hence the gender of the artist. Thus:
Table_CD:
CD_ID: Name: Artist:
1 CD1 Artist1
2 CD2 Artist1
3 CD3 Artist2
Table_Artist:
Name: Gender:
Artist1 Male
Artist2 Female
I need help, how to make one-to-many queries, for example:
I have 2 collections: customers, orders
customers{
customerId,
fullName,
company,
email,
}
orders{
orderId,
customerId,
createdAt,
}
I want to list all orders in a table with some customers data (customer full name, compa
Congratulations, you are alone in the dark Firestore Forest. Bring back all you have learned of DBMS at the college days and get you hands dirty.
Alternative 1:
First you need to filter the customers that satisfies your criteria. Then, load ALL your orders and filter mannually. I'm not kidding, saddly. The same applies if you need to order orders by customer name, for example. I'll be very happy to see someone downvote this for being wrong.
Reference: https://firebase.google.com/docs/firestore/query-data/queries
Alternative 2:
Stop using Firestore. I think you already done that.
I have a question in Entity Framework.
I have two tables: Customers and Addresses
The Customers table contains information about customers and Addresses contain information about the customer address. Both tables are linked together by CustomerID.
How can I get all Customers objects (from Customers) who are living in the USA (from Addresses) ?
Can anyone help?
You can use .Where like this:
List<Customer> usaCustomers = dbcontext.Customers.Where(c => c.Address.Country == "USA");
This assumes that:
Each customer has only one address
Address entity has Country property