I have a database of commands for a telephony switch, the relationships between tables are like so;
The issue I am having is when I use a form I have designed;
Used to view and enter data. I must allocate the data on the form to an overlay ID which is a primary key in overlays. I know what the form is trying to do when I enter new data and type in the relevant overlay ID, it is trying to add the overlay ID as a new overlay ID but the overlay ID already exists and therefore it cannot duplicate the ID.
I simply need to know how to I get my form to allow me to choose already existing overlay ID's (and the relevant linked overlay ID's) and allocate the information I am trying to add to it?
I have an understanding I can use a combo box but when I do this it changes the other records, when on the form, to no overlay ID and when you set the overlay ID in the combo box back to the original correct ID it just changes the rest of the records to that ID.
This is a university project and needs to have a minimum of 3 entities (tables) hence why there are some arguably unnecessary tables.
This could just be a silly question but I went into this project quite blind not really knowing much about access and now there is nobody to help!
Overlays are like the a section of the switch OS that allows you to carry out certain commands, so certain commands can be used in a certain overlay and that overlay will be linked with a select few overlays that can also carry out some of the same commands.
Turns out it's not as complicated as I thought, essentially I was working off of an unbound form (or rather it was bound to a query containing all relevant fields).
If I wanted to add a record against a primary key of another table as described above, I needed to bind the form to the PlainTextFunction table, the table that contains the information to be allocated to the PK. This allows me to change the FK on the PTF table record which in turn links it to the overlay ID required without changing or adding a new PK. Doh!
So to clarify; to do this you want to edit the foreign key of the record that needs to be classified under the PK of the other table. Which will, in a sense, allocate that record being entered to the PK in the other table.
Related
I'm building an Access Database, and I'm a database design rookie. I have two tables, we'll call them Parent and Child. These tables represent a one-to-many relationship in the direction that one Parent can have many children. This data comes to us in the form of a flat file that we import the initial parent-child relationship. Later, we manually add other child relationships to the parent as situations demand.
When I do the initial flat file import, I bring in a unique identifier that I place into both the parent and child. My understanding is this type of duplication is poor database design because it's duplicative. I want to avoid this if I can. I can't think of another way to draw the link.
The other question I have, is, it is my understanding that it is best to use the AutoNumber primary key to do any database references. 1. Am I just wrong here? 2. Is it okay to use the unique identifier that I bring in with the flat file? 3. If it is bad design to bring in the duplicative data, is there a way, during the import process, to draw this link automagically to the Primary Key (I already have a macro on this import process to tie it to a user form, adding to this macro is not an issue)?
The purpose of this:
There is a subform on the parent record that should list any related child records in the child record database.
It would be a lot easier if you had provided a simple example.
If your data already contain IDs, example:
P:1,XX,YY
C:1,1,blah
C:1,2,fuh
P:2,zz,ww
C:2,1,doh
..then it would be next to impossible to match to autonumbering.
Either skip the ID completely, or if it's important, make the ID a different column and just use autonumber to make sure records are different.
So that master is
AutoID, PID, F1, F2,...
and child is
AutoID, ParentID, ChildID, FC1, FC2, ...
then match parent.PID onto child.ParentID.
If there is only ever 1 parent per child, you can set Parent.PID to "unique".
In the end, I just imported the unique record to both the parent and the child and used that. It's working great. It changed how I built my manual new child record creation process, but it all works now.
The database i'm trying to create have four tables. tblPatient information, tblparasitology tests, tblserology tests and tblbiochemical tests. All the later three tables are related to patient information table. What i want to ask is that, is there a problem if i use the primary key in the table patient information to foreign keys of all the other tables? in other words how many tables (foreign keys) can be related to a primary key on one table?
There is really no practical or particular limit here.
however one tip, one concept to keep in mind?
While you can setup all these related tables, to create forms that edit the data?
Each form is STILL based on the one base table.
So you can create a form based on tblPatients.
So allow view and editing and adding of say tblserology results?
That will become a sub form. NOTE VERY careful here that the form tblPaitent is based ONLY on that one table. And the child table (and child form (ie: sub form) tblserology will ONLY be based on tblserology table. So the forms to hook up, wire up the relatonships between the tables are STILL only based on the single table.
To allow editing of related data, you thus use sub forms. If you do this correctly, then no code is required to edit and display and maintain say display of test results for a given patient.
So each and all tables will have a primary key (auto number id).
To realate a child table back up to a parent table, you create a plane jane long number column. This value will be automatic setup for you if you follow the above advice for a main form, and then a sub-form for the child table data.
Suppose I have a table called users. Inside users there are three columns: username, password and images. In the 'images' column the user should be able to upload images from the program as BLOBs and reaccess them as needed. So there should be multiple image items inside one row in the 'images' column per each user. The program will be in java jdbc.
This seems like a good time to use a different table. For example, adding a new table UserImages with columns of UserImageID, Username, Image with a foreign key on the Username and primary key on UserImageID lets you create a many-to-one mapping of images to users, which is what you're looking for.
Instead, if you put multiple (and of variable length) entries inside a single entry, then that defeats the purpose of database rdbms design. For more information, take a look at the first normal form of database. https://en.wikipedia.org/wiki/First_normal_form
Suppose I have a user table that stores the data of single user.
Initially we know nothing about the user, so there is nothing in the table(may be only single column like id which is of no use in this case ).
We do not know what are the details we are going to have about the user and we do not know in which order we are getting the details. Details about user will be obtained gradually in any order.
My question is ,For Example, if I got the name of user, how should I enter it in the table?
I have two options
1) Alter the table structure and add a column called username and store the data there. For all new detail, this process is repeated. So all data will be in one row.
2)Alter the table structure and add to columns key and value. Give name as a key and store the name of user as its value. Thus for each detail about the user,a new row is inserted as key value pairs.
First method makes the table grow horizontally.
Second one make it grow vertically.
which one is good on the basis of good design methods and ease of querying?
If you expect the metadata associated with a user could become arbitrarily large, then adding columns probably isn't the best approach. So this would leave your suggestion to simply add key/value pairs for each new feature associated with a user. There is a third option, which I don't like for so many reasons, which would be to store JSON containing key/value pairs in a single column of the user table. We currently use this approach sporadically, but we handle the JSON manipulation in our Java app layer, which is relatively painless. From a pure database point of view, this isn't so desirable.
So I would vote for your second option of using key/value pairs, because it would scale well. Note that this does not imply that your user table would only have a single column. You might know that a certain number of user attributes will always be there, e.g. username, hashed password, etc., and these columns could be added at the beginning.
Building on what others have already said, you could use a hybrid approach as well. If there are any predefined columns (username, firstname, lastname, password, etc.), you could put those in a table with defined fields, and then link a second table with key/value pairs for additional data.
I have an MS Access (2003) table containing names and addresses. The addresses are repeated for cohabiting people. I intend normalising this and putting it into My SQL.
To save time I used the Access 'analyser' to split the table into two tables 'People' and 'Addresses' linked by a foreign key 'addressID' (numeric) in the People table.
However, when I view the newly created 'People' table, instead of showing me that actual, numeric, foreign key it shows a column 'Lookup to Addresses' containing a textual address.
How do I make Access show me what is really in the table instead of trying to be helpful and showing me what it is linked to?
(An almost identical question was asked by Eyal in Dec 20011 but did not appeared to get any answers)
Finally found the answer. I had to...
go into the design of the table
select the foreign key field
go to the lookup tab
change the display control value from to combo box to
text box
go to the general tab
delete the caption text
All that bother!
This is what I don't like about MS products. They always seen to think they know better than the user does about what the user wants!
At last my table isn't lying to me about its actual contents any more.
Try querying the table using SQL (e.g. SELECT * FROM [mytable])
*fixed typo