A logical data model that allows users to edit data and approvers to approve or reject changes - data-modeling

As it says on the title, I have a project that needs to do just that. How do I implement the logical data model?
The actual nature of the data is not important. Let's say I am building a school database, and teachers can update a student's scores and other details. Once updated these will be stored in the database, but the changes will wait for the headteacher to approve or reject them.
Bear in mind that a teacher can make a number of changes in a session, e.g. changing a John's address, then entering Sally's latest math score and finally updating next month's timetable. The headteacher, upon logging on, should see a series of unapproved changes, go through them one by one, and approve or reject.
Assume that once Mr Jones has changed Sally's math score from 90 to 88, that change is visible only to Mr Jones and the headteacher. Everybody else will still see 90. Mrs Smith is allowed to still make more change to Sally's official score (90), so it's possble that when the headteacher logs in, s/he will see two updates:
Mr Jones' update from 90 to 88.
Mrs Smith's update from 90 to 85.
The headteacher will know which came after which and decide which to update and which to reject.
Thanks in advance.
PS. I'd especially like to know if any pattern is already available in the public domain.

I way to do it create a control table. Which will store all the approval details. Only head master will be able to add row in control table.
Also, create a staging table to store user inputs till final decision. This table should be visible to only users with update/insert access.
In your main table, create a trigger to insert data from staging to main table, whenever headmaster makes a commit.

Related

Implement "add to favorite" in database

I have a question regarding database/system design. We have a table user with user_id and a table school with school_id. We want to implement a feature so that users can add schools to their "favorites list". I already created a third table that contains the relationship between user_id and school_id. Now I have the two following questions:
When a user removes a school from "my favorites" list, should I delete it or keep it in the database but mark it as "deleted"? I want to keep it but it might leave tons of junk data in the table over time.
The front-end design looks similar to like/dislike button on twitter. User can favorite/unfavorite a school with one click. Is there any good way to prevent a bot from constantly hitting the the database by clicking the button?
Thanks in advance!
The answer depends on your application's logic. Both suggestions are ok.
If you need this data sometime in the future or if you are saving history of user actions then you can mark it as "deleted", else you can delete it immediately.
(another approach is mark it as deleted temporarily, and have a periodic job that cleans the table)
I don't have enough experience with this kind of threat, but a simple solution would be is to limit API calls per second per user

Microsoft Access Check in and out

I'm making a database up Microsoft Access to help simplify my job, but I'm relatively inexperienced with it, so I need some help. I'm running Access 2016.
I have a database set up for when students enter the IT Office seeking help, which essentially just records when they enter and what they're here for. So I've put a form on, which lets you enter your information, like your student number, what your problem is, and what your laptop number is. The date and time of your entry are automatically generated by the system clock. The student then presses "Check In", which creates a record based on the information they've just entered to keep track of problems. So here's my question, how would I conveniently give them an option to check back out? I need some way to update the record they've just made, without giving them access to all of the other transactions. I managed to make a list box which makes a list of all the student numbers of people who've entered today, but I'm unsure how to set the check out time of the student when they leave.
Hopefully I've explained that well enough. If you need me to clarify, please pop in a comment.
Thanks everyone.
For users to re-find their record, and not be able to look thru other records - you essentially just need an ID field that they type in; and use that as the query basis for the look up. Possibly the name they entered could be used if you aren't passing out trouble ticket IDs.
The check out info really doesn't have to be a separate table. It can all be part of the same record as the original check in. You can have a separate check out time stamp field that gets populated by a check out button.
The check in and check out may look like separate sides to user - with separate forms that is fine - but behind the scenes I see no reason to have separate tables. keep it simple.
www.CahabaData.com

How can anomalies (insertion,deletion and updation) be introduced into Oracle database?

I was trying to learn Normalization in Oracle database, but struck in understanding the problem for which normalization is the solution i.e. I am unable to understand different anomalies (insertion,deletion and updation) properly. Not that, I do not know anything about them; I learned the theory from my text book (Navathe & Elmsari). Anomaly is the problem raised in a database during these processes and result in inconsistent database. But I can not properly visualize it i.e. how can anomalies get introduced in the database. So, it will be very helpful if somebody comes up with a really simple database example and help me understand how can these anomalies be introduced in the database. I tried to find in the internet, but could not find good examples.
Anamoly: difficult to classify
The Problems resulting from data redundancy in an un-normalized database table are collectively known as update anomalies. So any database insertion, deletion or modification that leaves the database in an inconsistent state is said to have caused an update anomaly. They are classified as
Insertion anomalies: To insert the details of a new member of staff located at branch B1 into the Tbl_Staff_Branch Table shown above, we must enter the correct details of branch numner B1 so that the branch details are consistent with the values for branch B1 in other rows.
To insert the details of a new branch that currently has no members of staff into the Tbl_Staff_Branch table, it is necessory to enter nulls for the staff details which is not allowed as staffID is the primary key. But if you normalize Tbl_Staff_Branch, which is in Second Normal Form (2NF) to Third Normal Dorm (3NF), you end up with Tbl_Staff and Tbl_Branch and you shouldn't have the problems mentioned above.
Deletion anomalies: If we delete a row from the Tbl_Staff_Branch table that represents the last member of staff located at that branch, (for e.g. row with Branch numbers B",B3 or B4) the detals about that branch are also lost from the Database.
Modification anomalies: Should we need to change the address of a particular branch in the Tbl_Staff_Branch table, we must update the rows of all staff located at that branch. If this modification is not carried out on all the relevant rows, the database will become inconsistent.
Read more: http://www.mahipalreddy.com/dbdesign/dbqa.htm#update

How do I deal with concurrent changes in a web application?

Here are two potential workflows I would like to perform in a web application.
Variation 1
user sends request
server reads data
server modifies data
server saves modified data
Variation 2:
user sends request
server reads data
server sends data to user
user sends request with modifications
server saves modified data
In each of these cases, I am wondering: what are the standard approaches to ensuring that concurrent access to this service will produce sane results? (i.e. nobody's edit gets clobbered, values correspond to some ordering of the edits, etc.)
The situation is hypothetical, but here are some details of where I would likely need to deal with this in practice:
web application, but language unspecified
potentially, using a web framework
data store is a SQL relational database
the logic involved is too complex to express well in a query e.g. value = value + 1
I feel like I would prefer not to try and reinvent the wheel here. Surely these are well known problems with well known solutions. Please advise.
Thanks.
To the best of my knowledge, there is no general solution to the problem.
The root of the problem is that the user may retrieve data and stare at it on the screen for a long time before making an update and saving.
I know of three basic approaches:
When the user reads the database, lock the record, and don't release until the user saves any updates. In practice, this is wildly impractical. What if the user brings up a screen and then goes to lunch without saving? Or goes home for the day? Or is so frustrated trying to update this stupid record that he quits and never comes back?
Express your updates as deltas rather than destinations. To take the classic example, suppose you have a system that records stock in inventory. Every time there is a sale, you must subtract 1 (or more) from the inventory count.
So say the present quantity on hand is 10. User A creates a sale. Current quantity = 10. User B creates a sale. He also gets current quantity = 10. User A enters that two units are sold. New quantity = 10 - 2 = 8. Save. User B enters one unit sold. New quantity = 10 (the value he loaded) - 1 = 9. Save. Clearly, something went wrong.
Solution: Instead of writing "update inventory set quantity=9 where itemid=12345", write "update inventory set quantity=quantity-1 where itemid=12345". Then let the database queue the updates. This is very different from strategy #1, as the database only has to lock the record long enough to read it, make the update, and write it. It doesn't have to wait while someone stares at the screen.
Of course, this is only useable for changes that can be expressed as a delta. If you are, say, updating the customer's phone number, it's not going to work. (Like, old number is 555-1234. User A says to change it to 555-1235. That's a change of +1. User B says to change it to 555-1243. That's a change of +9. So total change is +10, the customer's new number is 555-1244. :-) ) But in cases like that, "last user to click the enter key wins" is probably the best you can do anyway.
On update, check that relevant fields in the database match your "from" value. For example, say you work for a law firm negotiating contracts for your clients. You have a screen where a user can enter notes about negotiations. User A brings up a contract record. User B brings up the same contract record. User A enters that he just spoke to the other party on the phone and they are agreeable to the proposed terms. User B, who has also been trying to call the other party, enters that they are not responding to phone calls and he suspects they are stonewalling. User A clicks save. Do we want user B's comments to overwrite user A's? Probably not. Instead we display a message indicating that the notes have been changed since he read the record, and allowing him to see the new value before deciding whether to proceed with the save, abort, or enter something different.
[Note: the forum is automatically renumbering my numbered lists. I'm not sure how to override this.]
If you do not have transactions in mysql, you can use the update command to ensure that the data is not corrupted.
UPDATE tableA SET status=2 WHERE status = 1
If status is one, then only one process well get the result that a record was updated. In the code below, returns -1 if the update was NOT executed (if there were no rows to update).
PreparedStatement query;
query = connection.prepareStatement(s);
int rows = -1;
try
{
rows = query.executeUpdate();
query.close();
}
catch (Exception e)
{
e.printStackTrace();
}
return rows;
Things are simple in the application layer - every request is served by a different thread (or process), so unless you have state in your processing classes (services), everything is safe.
Things get more complicated when you reach the database - i.e. where the state is held. There you need transactions to ensure that everything is ok.
Transactions have a set of properties - ACID, that "guarantee database transactions are processed reliably".

Best practices for managing updating a database with a complex set of changes

I am writing an application where I have some publicly available information in a database which I want the users to be able to edit. The information is not textual like a wiki but is similar in concept because the edits bring the public information increasingly closer to the truth. The changes will affect multiple tables and the update needs to be automatically checked before affecting the public tables.
I'm working on the design and I'm wondering if there are any best practices that might help with some particular issues.
I want to provide undo capability.
I want to show the user the combined result of all their changes.
When the user says they're done, I need to check the underlying public data to make sure it hasn't been changed by somebody else.
My current plan is to have the user work in a set of tables setup to be a private working area. Once they're ready they can kick off a process to check everything and update the public tables. Undo can be recorded using Command pattern saving to a table.
Are there any techniques I might have missed or useful papers or patterns?
Thanks in advance!
I would do it like this:
Use insert only databases, you never update data only add new rows
Each row has a valid from date, a valid to date and who made the change
Read the data through a query where the valid to date = null, and the row is approved, this gives the most recent row
When a user adds data, he can see his changes by selecting the last row that he added
When the user is happy with the changes he has made he can mark them as approved
When they are approved they can be seen by other users
Undo is not a problem since you have all the previous versions, you can mark a row as no longer being approved and revert to a previous version.

Resources