Above is my normalised database structure for my app. I am going to store Users, and their favorited Images. Images might be alone (hosted on reddit) or in albums (hosted on imgur), and they always have a title.
Question is - is the database set up correctly? I have this feeling that i have something wrong with ImageAlbum and Image table relationship.
EDIT: This might work?
The main issue with the original design is that the intended relationship between a user and an image would not be possible, as the two tables are not connected.
As a general rule of thumb, if there's a 1-1 or a 1-many relationship between tables, you can rely on constraints. I.e. 1 customer can place many orders. You have a Customer table with a CustomerID PK column, and an Order table containing an OrderID PK column, and a Foreign Key constraint to the CustomerID column of the Customer table. That establishes the relationship, and ensures that you cannot place an order if you are not a customer.
An order typically consists of one or more products, and a product typically can be purchases in multiple orders. In cases like this, you cannot set up this relationship the same way. A common workaround for that is to do so using an intermediate table that establishes the many-to-many relationship.
So building on the earlier tables, we also have a Product table, with a ProductID column as a PK. To set up the relationship between Order and Product, you would then credit an OrderProduct table, with FKs pointing to the OrderID and ProductID in question (and probably also something indicating quantity of products for this particular order, and perhaps something like a FK to a Discount or campaign table, and whatnot).
So in your scenario, I would establish the relationship between Image and User using a similar approach, and simply adding a UserImage table to allow for the many-to-many relationship. You then also add an AlbumImage table to determine the many-to-many relationship between images and albums.
As indicated in the comments, there's no need to have an AlbumTitle table, really. It would naturally belong to the Album table. The ImageTitle would belong in the UserImage table, because every user can add their own title to an image.
Related
Currently I'm designing a database model that would serve as a database for an inventory system. However, I'm facing difficulties in the database structures particularly on whether I would add an extra column for the parent table for it's child ID.
Presented in the figure below is a part of the database that I'm currently working on. I'm working on the Normalization forms that's why it already has multiple tables. However, in the Shipment Table (highlighted in blue) in this case the parent table of Shipment Details (highlighted in red) I don't know if I should include an extra column for the shipment table for it to identify or connect to the Shipment Detail table.
I already included a foreign key for the Shipment Detail for it to identify which Shipment it relates to I just don't know if I should add another ID column for the details in the Shipment table. To be more specific, should I add a "Shipment Detail ID" column for the Shipment table? I worry it might result to redundancies if I include it.
If each shipment has exactly one shipment detail
shipment {SHIPMENT_ID, ...}
PK {SHIPMENT_ID}
shipment_detail {SHIPMENT_ID, ...}
PK {SHIPMENT_ID}
FK {SHIPMENT_ID} REFERENCES
shipment {SHIPMENT_ID}
If each shipment can have more than one shipment detail
shipment {SHIPMENT_ID, ...}
PK {SHIPMENT_ID}
shipment_detail {SHIPMENT_ID, SHP_DET_NO, ... }
PK {SHIPMENT_ID, SHP_DET_NO}
FK {SHIPMENT_ID} REFERENCES
shipment {SHIPMENT_ID}
Notes:
All attributes (columns) NOT NULL
PK = Primary Key
AK = Alternate Key (Unique)
FK = Foreign Key
It depends. If you want a Shipment to have many ShipmentDetails then no, because you're going to repeat ShipmentDetailId in the Shipment table for every child it has, an thus violating 1FN.
If you have a "1 to 1" relationship, having two tables might not be necessary because you can have everything in just the Shipment table.
I've seen tables that became too large in columns amount let's say, but I've never seen a performance boost for separating the columns in different tables.
Hope this helps!
I am using MS Access 2016 and I created tables (entities) Employees and Managers with the following attributes:
Employees
-EmployeeId (Primary key)
-Name
-LastName
-Email
-Phone
Managers
-ManagerId (Primary Key)
-EmployeeId (Foreign Key & Unique)
-Position
I am trying to create a relationship between the 2 entities that meet the following requirements:
Managers(EmployeeId) is a unique value.
for every record in Managers table there has to be one record in the Employees table (because the manager is an employee)
I can create a one to one relationship between the tables and I think that is fine because there can only be one ManagerId per EmployeeId (When the employee is actually a manager) but my issue is that when I add a record in my Employees tables Access is forcing me to have a record in the managers table even when I am adding a non-manager to the Employees table. Any suggestions on how I can create a relationship between the 2 tables is greatly appreciated.
When defining a relationship using the visual Relationships window, Access usually does a good job determining which is the primary table and which is the "related" table based on the indexes of the fields being related. But for a 1-to-1 relationship where the indexes on both fields are unique, Access uses the first table you click as the primary table and the second table--the one you dragged the first field onto--as the related table. Thus, it requires that a value be in the primary table before the related table record can be added. I assume that you defined the relationship by click and dragging in the wrong order/direction.
Delete the existing relationship between the tables. Then redefine the relationship by first clicking on the Employees.EmployeeId field, then dragging that field to the Managers.EmployeeId. The relationship window which pops up should show Table/Query: Employees on the left with Related Table/Query: Managers on the right.
I want to make an ER diagram involving a 1 to many relationship. Should I add the attribute of the relationship on the N side too? And if possible write the correct ER diagram.
Take a simple example of many people working in one department with a constraint that a single person can work only in one department. That makes department connected to people in a one-to-many fashion.
The simplest way to represent this is to add the primary key of you department table as a foreign key in your people table.
The schema will look something like this
DEPARTMENT (dept_no, dept_name, dept_location,....)
PEOPLE (p_no, dept_works, p_name, p_dob,....)
Where, dept_works in PEOPLE table is the foreign key that references the dept_no Primary key in the DEPARTMENTS table. This way you can store the ID of the department for each person in which he/she works.
I'm developing a system for a retailer and I've hit a bit of a conundrum when it comes to deciding how to represent the orders in the database. The schema for my Order table so far is as follows:
Id - PK
AccountId - FK (Nullable)
ShippingAddressId - FK (Nullable)
BillingAddressId - FK (Nullable)
ShippingMethod - (Nullable)
Type - (Nullable)
Status
Date
SubTotal
Tax
Total
My problem is I'm not sure whether I should represent online purchases and in-store purcahses in separate tables or not. If I were to store them in the same table, all non-nullable fields would be the only ones applicable for in-store purchases.
Another design pattern that crossed my mind is something like this:
Online order table:
PurchaseId - PK, FK
AccountId - FK
ShippingAddressId - FK
BillingAddressId - FK
ShippingMethod
Type
Purchase table:
Id - PK
Status
Date
SubTotal
Tax
Total
And for in-store purchases, there would simply be no reference from the online orders table.
Thoughts?
I would make a second table for location, with a primary key and location information. That could be online as well. Then use a foriegn key in your main table. You would then just fill the fields require for the application you are doing(in store, or online). This would also allow For the business to grow to more locations just by simply adding it into the location table.
I'm going with the original design. Likely more maintainable and efficient as well.
Your second design is very close to an Entity Sub-typing pattern. If the primary key of your online order table was the foreign key to your purchase table then you would have entity sub-typing.
Your original design is a practical design for the physical implementation of your database because it is simple to use. Entity sub-typing would be the preferred design at the logical level because it clearly represents your rules about which predicates (columns) belong to which logical tables.
Some people would also use the entity sub-typing pattern for their physical model too because they have an aversion to nulls.
I have a few database tables that really only require a unique id that references another table e.g.
Customer Holiday
******** *******
ID (PK) ---> CustomerID (PK)
Forename From
Surname To
....
These tables such as Holiday, only really exist to hold information regarding a Customer. Therefore, do I need to specify a separate field to hold the ID for the holiday? i.e.
Holiday
*******
ID (PK)
CustomerID (FK)
...
Or would I be ok, in this instance, to just set the CustomerID as the primary key in the table?
Regards,
James.
This really depends on what you are doing.
if each customer can have only 1 holiday, then yes, you could make the customerid the primary key.
If each customer can have multiple holidays, then no, you would want to add a new id column, make it the primary. This allows you to select holidays by each customer AND to select individual records by their unique id.
Additionally if each customer can only have 1 holiday, I'd just add the holiday information to the table, as a one-to-one relationship is typically un-necessary.
If I understand your question correctly, you could only use the Customer table as a primary key in Holiday if there will never be any other holiday for that customer in the table. In other words, two holidays for one customer breaks using the Customer id as a primary key.
If there will ever be an object-oriented program associated with this database, each entity (each row) must have a unique key.
Your second design assures that each instance of Holiday can be uniquely identified and processed by an OO application using a simple Object-Relational Mapping.
Generally, it's best to assure that every entity in the database has a unique, immutable, system-assigned ("surrogate") key. Other "natural" keys can have unique indexes, constraints, etc., to fit the business logic.
Previous answer correct, but also remember, you could have 2 seperate primary keys in each table, and the "holiday" table would have the foreign key to CustomerId.
Then you could manage the assignment of holidays to customers in your code, to make sure that only one holiday can be assigned to a customer, but this brings in the problem concurrency, being 2 people adding a holiday to a customer at the same time will most probably result in a customer having 2 holidays.
You could even place holiday fields in the customer table if a customer can only be created with a holiday, but this design is messy, and not really advised
So once again, option in your question 2 still the best way to go, just giving you your options.
In practice I've found that every table should have a unique primary key identifying the records in those tables. All relationships with other tables should be explicitly declared.
This helps others understand the relationships better, especially if they use a tool to reverse-engineer the schema into a visual representation.
In addition, it gives you more flexibility to expand your solution in the future. You may only have one holiday per customer now, but this is much more difficult to change if you make customer ID the primary key.
If you want to mandate the uniqueness of customer in the holiday table, create a unique index on that foreign key. In fact, this could improve performance when querying on customer ID (although I'm guessing you won't see enough records to notice this improvement).