Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
when we have two tables, suppose A and B,there exists one to many relationship between these two, than can there be element from A that are not connected to any element from B?
One to many relationship between relational tables is a concept that primarily means that if there is a record in table A, then it can have many associated records in table B.
For e.g. customer_id record in table A can have many loans for that customer in table B.
So 1 customer_id associated with many loan_ids in another table.
Coming back to your question, it is possible that 1 loan_id in loan_table can have multiple guarantors in guarantor_table and it is also possible that a loan does not have a guarantor associated with it. So even though there is one to many relationship between the tables it does not mean it will always have many records in table B for one record in table A.
Check this link - What is the difference of partiality and optionality when drawing ER diagrams
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am implementing a seat booking application. I have a problem. There is a booking table. If two users try to book a same seat exact same time it will be a problem. How can I overcome this problem. I am using Java 8 and PostgreSQL.
A database system is designed to handle concurrent queries like in your situation by itself.
You however need to make sure, that a seat can only be booked once.
Solution #1 If you insert a new entry in the booking table for each booked seat
INSERT INTO booking (booking_id, seat_id, customer_id)
SELECT ?,?,?
WHERE NOT EXISTS (SELECT seat_id FROM booking WHERE seat_id=?)
This solution will check if there is already a booking entry in the database with the seat_id you are trying to book. This can be also achieved by putting an unique constraint on the seat_id attribute in your table. However in this case your query will fail with an error - since the unique constraint is violated when inserting a duplicated value - while in the solution above the query will execute sucessfully and just not insert any value. This solution is prefered.
Solution #2 If you have one row for every seat in your database and just need to update if its booked
UPDATE booking
SET booking_id=?, booked=true
WHERE seat_id=? AND booked = false
Depending on your JDBC library you are able to replace the ? with your real values.
The database system will handle concurrent queries and only allow one query to pass.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
For background, my situation is I have a database that is missing a lot of foreign key relationships. One in particular, let's call it Orders, which represents orders with a composite primary key of OrderID and LocationID. The other table we'll call OrderDetails which has an OrderID but no LocationID. In reality, it is impossible to have an order in two locations at once, so it was assumed that there was no need to have LocationID in the details table. I didn't design it, and I can't change that.
We also have to work under the assumption there will be no support to add location id to the details table for various reasons. We are also working with Oracle and a high volume database with many concurrent users in many locations. Finally, there will be minimal time to change any applications that use this table.
So my question is: is this solution is feasible, or is there anything else I should try?
Say I create an intersection table, for lack of a better name AllOrders or whatever with primary key OrderID. Now we link Order.OrderID to AllOrders.OrderID and link OrderDetails.OrderID to AllOrders.OrderID. Would it be reasonable then to fill in AllOrders via a trigger on each insert to Orders to enforce the integrity? I am assuming all applications are inserting details after orders or the changes to enforce would be minimal and allowed.
Are there any better solutions? I understand we would do this differently if in charge of designing or given more leeway for fixing, but I'm trying to make the most given the constraints.
Edit --
To clarify what I am looking to accomplish, I want to treat all orders with the same ID as an equivalence class modulo location and ensure that if any order is deleted it requires all orders with the same id deleted and all child order details to be deleted. With primary importance of no orphan details. This has to be done with minimal application changes if possible and no redesign of existing tables if possible.
Create a new table to handle the mapping going forward.
Table: Tb_order_orderdetails
Columns: OrderID, LocationID, OrderDetailsID
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am kind of confused when I question like "what is decomposition?" and "how can you decompose your database and data?"
Can somebody give me a clear explanation for the questions above?
Thank you.
Suppose we have a schema, Lending-schema
Lending-schema = (bname, bcity, assets, cname, loan#, amount)
A tuple t in this relation has the following attributes:
t[assets] is the assets for [bname]
t[bcity] is the city for t[bname]
t[loan#] is the loan number made by branch t[bname] to t[cname].
t[amount] is the amount of the loan for t[loan#]
If we wish to add a loan to our database, we need a tuple with all the attributes required for Lending-schema.
Thus we need to insert
(SFU, Burnaby, 2M, Turner, L-31, 1K)
We are now repeating the assets and branch city information for every loan.
Repetition of information wastes space.
Repetition of information complicates updating.
We need to change many tuples if the branch's assets change.
So after analyzing this
We know that a branch is located in exactly one city.
We also know that a branch may make many loans.
Another problem is that we cannot represent the information for a branch (assets and city) unless we have a tuple for a loan at that branch.
Unless we use nulls, we can only have this information when there are loans, and must delete it when the last loan is paid off.
So if we decompose into two schemas
Branch-customer-schema = (bname, bcity, assets, cname)
Customer-loan-schema = (cname, loan#, amount)
These two tables are formed after decomposing the main table.
In Short : Dividing a table into multiple tables is Decomposition. Our decomposition should be a lossless-join decomposition
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
This may be a classical requirement. Two key concepts objects and items, a time-change demand, the items can changed very quickly.
Such as a person have so many salary items, and these items will be added and changed or deleted.
Our solution is so simple, it's a 500 columns table, and map items to columns.
This beyond to hard code. This solutions have so many disadvantage.
**What's the classical solution about this requirement**
As I gather from your question, this is a classical one-to-many (1-M) relationship. The one side is the (object) and the many side is the (item). The item should have a column that points to its 'parent object'. This is column could contain the value of the Primary Key of the parent table (usually referred to as Foreign Key). The child table (the item) could have validity period (such as start date, end date) as well as other control columns in addition to the business columns (such as salary amount, etc.). This design is typical in Normalized database modeling.
There are many advantages of this design. One of them that pertains to you case, is that you don't have to have large number of columns, instead, you'd have several rows which allows you to fetch just what you want to satisfy most business queries. Similarly Create and Update operations will deal with much smaller rows, hence increasing the performance of the application.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have 2 tables User and User_Event
User
id PK BIGINT
User_Event
event_id PK BIGINT
user_id FK References User.id
Should I create above tables before runtime
OR
should I create table "User_Event" for each Existing user at runtime (In this case table name would be like this
User_Event_user001,User_Event_user002....)
Now my questions is
1. Which design is better?
2. which implementation is faster?
For both questions, the best answer is to have an invariant database structure.
Modifying/creating the tables is a lot of work for databases, as they are designed for managing DATA inside the defined structures (tables, views).
It is very rare that changing the structure on the fly is pertinent, and even less effective.
--> create tables before runtime !
I don't know what is purpose of your system but classical implementation is to have one table User_Event and store data about all users in this table. If you want to get info for one user you should use query:
SELECT event_id FROM User_Event where user_id=<your user_id>;