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.
Related
As the title described, I am looking for a database constraint that can make sure a new inserted parent row always has at least one child row.
Say I have a company table and a document table. The business rule is that
each company can have multiple documents so company table and document table is one to many relation;
each company must have at least one document.
I would like to do the check in the database level so that whenever a new company is created, there must be a document inserted in the same transaction.
Is there such a constraint?
By the way I use MySQL and JPA so I am also happy to use JPA annotations to do the check if there is any.
You would need to use trigger (BEFORE INSERT) for that but it's not really good practice. I would suggest to check it in the transaction directly. Just before insert , check by select. The triggers are nightmare for visibility.
In the (MySQL) database, I'm storing a view hierarchy, with each row in a table referring to a single view. There are several types of views, but they're stored in the same table.
In the application code, each type of view has its own class. Each row in the database instantiates one of these classes.
How should I refer to these classes from the database, so the application knows which class to use?
I can think of several possibilities:
Just specify the class name directly in the table, but this has the disadvantage of having to change lots of rows if the class name changes (which can be done in a single query if required).
Have a separate table storing class names, and use foreign keys to point to the row storing the correct class name. In this case, I could forgo having an ID field in this lookup table and instead have the class name as the primary key and target foreign key, and rely on a cascading UPDATE if the class name changes?
Are there better options available?
If I understand correctly you want to maintain an association between view-names and class-names.
Your bullets suggests, that there can be more than one view for the same class and both of your suggestions would work. The second bullet has the advantage that you can change the class name with a single update. But that doesn't buy you much, because as soon as more than just a single class-name changes, i.e. when the association itself changes, you need to update more than one row.
You might even create a separate table, holding this association. This would be the model for an n:m relationship, which is too general, so you'd have to place a unique constraint on the view-name. Essentially this will just factor out the concern of associating view-names with class-names and allow you to change this mechanism entirely without having to mess with your tables (except the one holding this association).
But actually I would not store any of this stuff in the database
(I also find it irritating that view-names are stored in the database and not in the application logic). The fact that there are class-names, should be of no concern to your database. This is application logic and it should be handled there. So what you need is a way to instantiate an object when the view-name is known. This looks like a classic factory to me. After all, if a class name changes, it is a change in the application code and life is easier, when all resulting changes lie in the application code as well.
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.
I have a table structure for categories,
Each category can have many children, but can only be a child of one category.
I am deciding whether I should just add a parent_id column to the table, or whether I should add a reference table that just has the parent_id and child_id and maps them together.
If it is important a category can have no parent, in which case it is a root category.
The most common use cases for this table will be:
Selecting one category
Selecting all categories
Selecting all children of a category
Selecting the parent of a category
Selecting the child tree of a category
As far as I can tell there is no benefit of having a reference table for this setup? can anyone see any reason for using a reference table?
If you add a reference table, you create an n:n relationship, which you don't want.
So just add a parent_id to the table.
Make it nullable so you can define a category as the root.
Everything you want to select is quite easy, except for the child tree, but an extra table won't help with that. In Oracle you got connect by to select tree-like data, but MySQL unfortunatly doesn't support that, although alternative solutions are often requested and provided.
There are some obstacles:
Since you cannot make parent_id unique (multiple childs can have the same parent), you will have to add a trigger to enforce only one category being the root, although maybe you can live without that check for the moment.
You could theoretically create a loop: Make a the parent of b, b the parent of c, and c the parent of a. To check if this is the case, you should follow the path to the root. If on that path you'll find any category twice, you're in trouble. I think you could use a trigger to validate this as well, although maybe you can live without that check for the moment. It all depends on how you edit your data, but if you are going to query a full tree, you don't want to get into endless loops because of corrupt data.
So the root of this problem may lie in poor database design, some of the way this is set up is inherited from older versions. I just couldn't figure out a better way to do this.
I have four tables linked by the same field: [OBJECTID]. Each table is linked to an Access Form that controls the data. It is important that these tables be separate as the data is georeferenced and needs to be mapped separately, however they inherit several fields from one another by default.
Most of the time, the tables are in a one-to-one-to-one-to-one relationship, however occasionally, there is only data for the first table, and occasionally, there is only data for the second, third and fourth form.
Right now, the [OBJECTID] field in the first table is set to datatype autonumber, so that all subsequent linked records in the other tables can inherit that number. For the cases where the record in Tbl1 are not entered via Form1, it is easy enough to just assign a number that does not conflict with any current number, but how do I avoid assigning a number that could conflict with some future [OBJECTID] generated by the autonumber field in Tbl1?
Sorry if that is confusing! Thanks in advance for helping me think this through....
If the design is correct, there should be a relationship with referential integrity between tbl1 and table 2/3/4. Since you mention that occasionally, there is only data for the second, third and fourth form that means we have no referential integrity here :-/.
I would identify the fields that are common to all 4 tables, and create a "main" table with those, meaning that the main table MUST be filled. Then you create a 1 to 0,1 relationship to the other 4 tables, with an outer join, their PK beeing then a Long Integer.
For the source of your forms 1 to 4, use an outer join between MainTable and T1/2/3/4. The "subtables" will then inherit the PK of the main table.
Hope I am not too obscure.