Linking user accounts to primary key values in Oracle Apex - sql

Im brand new to Apex and fairly new to SQL. I made a database that has teachers and students. I want to make an oracle apex application such that when teachers make a new course students can sign up to it. However, since there are many teachers how do i make a form in Apex so that it knows what teacher i am referring to? I wouldnt expect teachers to have to enter their teacher_id (primary key) but dont know what to do.
I made a sequence and trigger so that when a teacher makes a new course listing, a new row goes to the database. What i am stuck on is how apex can identify which teacher is posting that. I have tried to make different users as well but have no idea how to link a teacher user account on apex to a teacher_id (primary key) value in my database so that whenever a specific teacher logs into the apex application, the database knows their teacher_id and uses that automatically whenever a teacher_id is required.
Any form of guidance will be helpful (even a link to a useful youtube video that addresses my problem - I have searched to no avail thus far).
Thanks.

A simple option would be to identify teachers (and students) by their usernames (they use to log in into your Apex application). In Apex, it is then referenced as :APP_USER variable. As there can't be duplicates (obviously), it will be unique so there won't be any confusion.
So, alter the users table and - along with their ID (which you already have) - add the USERNAME column (or APP_USER, or whatever you want to name it).

Based on the information that you have provided, I gather that you have got the tables for the teacher in place. Also, I understand that this table has a primary key of teacher_id.
Now in the course creation form, you can have a field that is mapped to this primary_key column. For display purposes, you can make this field resolve the teacher name (instead of the teacher_id) value. You can achieve this by associating the field with a List of Values (either via a Shared Component).
There are multiple configuration options to achieve this. Here is a link to help you get started on this.
Oracle Apex - LoVs
Once, you have the field render user-friendly data, if you would like it to be auto-populated based on the logged in user, you can take the approach that #Littlefoot has suggested above and link the :APP_USER with the teacher_id and use that to set the default value into this field.

Related

Storing full name of database user

I have a QT application which uses database with several users (teachers in my case). I also have a table with teachers' names and information about them. Teacher logs in with his username and password at the beginning and then I need his full name somewhere in the program.
How should I retrieve it? Is there some way to store it in the table of db users? Or should I add column with username to my Teachers table? (It is my first application where I use databases so I'm sorry if this was asked before, I have no idea what I should google)
Database structure: https://yadi.sk/i/EmNwwsl7ia5JS
It's better to add two columns, for first name and last name, in the table where the username exists. So by using the username we can fetch the full name from the table.

How can I duplicate patient information in Microsoft Access?

I am working for a hospital building a patient recording system on Microsoft Access.
One of the Doctor's requests is that when they are seeing patients that are siblings, is there any way that they do not have to type in duplicate information for these relatives? (Address, phone number, town of residence, etc...)
I understand that the ID number will change for each patient. Say the form goes like this:
1) Does patient have other siblings at risk? (Y/N)
2) If so, how many?
Depending on the digit that answers question two, could I duplicate the primary patient's information so that it exists in 3 different files? The doctor is adamant that it would be easier to go back and alter a few fields than it would be to type them repetitively.
Is this possible? Are there any shortcuts to doing so?
It sounds like you need a table called RESIDENCES, which would have an id, address, phone number etc. A patient record would include a foreign key to this table's id. When a sibling is added, the sibling record would include the same foreign key. The tricky part of doing this would be in the user interface: when a new patient is about to be added, you will have to ask whether this patient is a sibling of someone. If yes, you will have to ask who the sibling is, then copy the 'residences' foreign key; if no, you will have to display a dialog which allows the 'residencies' data to be added.
But what happens if a sibling changes address or has a separate telephone number? In that case, the contact details of each person would be stored in the patient record, without a 'residences' table; your user interface could include a function which copies contact data from record to record.
I think that this approach is better because each person has his own contact data which is independent from everyone else. The problem which you stated is more an interface problem (how do I add this functionality to make things easier for the users?) than a data modelling problem (how should the data be stored?).

Same form that submits to two different tables

I am quite new to Microsoft Access but i have been working with databases for quite a while now, so I understand "the back end" (so to speak) as to how I will set up this database, but I'm not sure how to tell Access what to do and how to do it.
The aim of my database is to load up a customer's account with their information; eg, phone number address, email, etc. All this information has been migrated to a table within my new database project.
from here I would like to create a separate table which has notes which can be assigned to each user's account number. the aim of this is to be able to read up on recent activity of these customers and be able to search and filter that information on an easy to use front end interface.
So so far I have two tables, one with the customer's information in it and another which is where I would like to save the notes for each customer.
the primary key which I will be using is the customer's account numbers. This, of course, being unique to each customer and would be perfect for the primary key in both of these tables.
I have set up a relationship between both of the tables as they will both contain the user's account numbers.
I'm just not sure how to go about it and would really appreciate the help. I am currently using Microsoft Access 2007.
for your second table you need to use a new primary key like "customerInformationID". Reference the customer table by a foreign key.
Then you can join these tables like this:
SELECT c.Name, c.Number, ci.notes
FROM customer AS c
INNER JOIN customerInformation AS ci ON c.customerID = ci.customerID
Why do you need two tables anyways? If you don't need them for a technical purpose like "every user shall be able to store his own notes to a customer" then you can also store them in your main table as all of these information are only dependent from the primary key.
Best Regards
Bruellhusten

Database design relations in User and Profile

I'm designing a web application for a school. So far, I'm stuck with the database which has these tables:
users
id
username
password
profile
user_id (FK)
name
last_name
sex
group_id (FK)
(other basic information)
... And other tables irrelevant now, like events, comitees, groups and so on.
So, the users table stores basic information about the login, and the profiles table stores all the personal data about the user.
Now, the *group_id* column in the profile table has a foreign key that references the ID column of the group in which the user is currently enrolled, in the groups table. A user can only be enrolled in one group at once, so there's no need for any additional tables.
The thing is that it doesn't make much sense to me declaring a relation like group HAS MANY profiles. Instead, the relation should be group HAS MANY users, but then, I would have to put a *group_id* column on the users table, which doesn't really fit in, since the users table only stores auth information.
On the other side, I would like to list all the users enrolled in a group using an ORM and getting the a users collection and not profiles. The way I see it, is that the users table is like the 'parent' and the profiles table extends the users table.
The same problem would occur when setting attendances for events. Should I reference the profile as a foreign key in the events_attendance table? Or should I reference the user ID?
Of course both solutions could be implemented and work, but which of them is the best choice?
I have dug a little and found that both solutions would comply with 3NF, so in theory, would be correct, but I'm having a hard time designing the right way my database.
This is a question of your own conventions. You need to decide what is the main entity, right after that you can easiy find a proper solution. Both ways are good, but if you think of User as of the main entity while Profile is a property then you should put GroupId into User, otherwise, if you mean User and Profile as a single entity, you can leave GroupId in Profile, and by this you're not saying group HAS MANY profiles but group HAS MANY users.
By setting a proper one-to-one relation (User-Profile) you can force your data integrity good enough.

Audit columns - join or copy?

I have seen many business systems not using joins on Users table but instead copying user name (or firstname+lastname) to a CreatedBy audit field.
I already see one issue with this approach - a user might marry and change her last name, and then CreatedBy field will keep the old value.
Is there any good reason why to draw back from data normalization and create redundant text data for the CreatedBy field?
Storing someone's name without using a foreign key reference lets you delete users without affecting information about which rows they created. Whether this is wise is application-dependent.
In most organizations, if it's important to know what someone's name was 3 years ago, there's some way to do it. It might not be in the database. It might be, "Go ask Jerry in HR. He remembers everyone." Whether this is wise is also application-dependent.
In any case, this doesn't necessarily violate any guidelines of normalization. In the one case, you're storing the current name or the preferred name of a user. In the other case, you're storing the name of a user at the time the row was created, and that still constitutes a true fact.