I have created a workflow system where users can see their work in a queue, mark it complete, and create an outgoing correspondence letter. In the Access DB, essentially they are going into each record which has an "Incomplete" indicator and marking items as "Complete" from the queue table. After doing this, an insert is triggered, which inserts customer data based on that record being marked into a letter table. A pdf is then batched/printed based on the inserted data from this letter table.
The beginning scope of the project was a single transaction type with essentially limited data fields Such as: Name, Address, State, Zip. I am finding now that I am being asked to expand the transaction types in the queue. Different letters however, require different fields and not all fields are readily available for each letter (Some letters need and have an account issued date, others do not, etc).
My question pertains to the methodology of "expanding" the fields available for letter insert. I need to add more fields for the new transaction types in the letter table. But these fields are transaction specific, so for example, I may have some kind of audit letter that does not use account premiums, but now I have another transaction that uses only account premiums. All my letters in the table will share that field if I create it, regardless of whether they actually use it or not. So if that is the case, how should I deal with the nulls? I am wondering if I should still create the field aptly named (such as "AccountPremium", or should i use generic names like "extraField1" and just match it to the point in the letter??
Related
This question already has answers here:
How can you represent inheritance in a database?
(7 answers)
How to design a product table for many kinds of product where each product has many parameters
(4 answers)
Closed 1 year ago.
I'm trying to build a letter of statement request system using MySQL as its DBMS. I don't know if "letter of statement request" is the appropriate term, but the system is meant to provide simplicity for college students to request a letter of statement from their faculty or university; such as active student certificate, research permit, etc. I have started to make the system but now doubt whether the database structure (just part of it) is ideal.
Here's the overall flow of how the system works:
Student sends a request for a letter of statement to the system. There are many available types of letters, but they can only request one type at a time.
Each type of letter will require different data to input. For example, an active student certificate requires the data of the current semester of the student and the destination institute where the certificate will be used; while a research permit requires the data of research title, the institute/place where the research will be held, time of research, research subjects, etc. This is where the confusion and doubt hit me.
The requested letter will be then gets verified by officers and will be sent to the student if gets approved.
Here's the (partial) database structure in question (Tailored for simplicity)
letter_type
type_id (primary key)
description
letters
id (primary key )
letter_type (foreign key)
submitted_at
necessity
letter_position
status
active_student
letter_id (primary key, foreign key)
semester
destination_institute
research_permit
letter_id (primary key, foreign key)
title
institute
duration
subject
The letters table is used to record the overall data of the letter, including the id of the student, type of the letter, submission date, etc.
The two other tables, active_student and research_permit, are used to record the 'detail' data of the letter. Meaning that the data of a request for an active student certificate will be written in letters and active_student, while a request for a research permit is written in letters and research_permit
letters table will use its letter_type field to determine which table it should be referencing.
Finally, here's the question:
Is my database structure ideal? If not, what's the better approach available?
Additional context
I'm making the system using Laravel 8. The code for creating a new record of letters is easy because each type of letter is handled by a different controller. The difficulty comes when I want to make the code for retrieving a set of letters' records (for example letters sent by a student with id 'X001'). What makes it difficult is because I need to retrieve records from the letters table along with its 'detail' data in the referencing table of each record (there are more than just two types of letters actually).
Actually, I would like to ask about how to do this in Laravel. But before that, I want to make sure that my database structure is correct.
This is a very good question in my opinion. You are worried that in order to enter the data for a particular request you need a table for that request with all its obligatory (and maybe optional) columns. Every time you want a new request type in your system, you'll have to add a table for this and change the software.
This is one of the few cases where a key/value table might be an appropriate choice. Here is an example:
letter_type (letter_type_no, name)
letter_type_field (letter_type_no, field_name, is_obligatory)
letter_request (letter_type_id, student_no, date, status)
letter_request_field (letter_type_id, student_no, field_name, field_value)
Key/value tables are a nuisance to work with. If you have just one table for them the values must be strings for instance and dates and numbers must be stored in an agreed format. Validity checks are hard to implement. The list goes on. But for a new letter type, you just add that type to the letter_type table and list all required fields in the letter_type_field table, and all your queries and software can work with this.
Another and probably better approach, though, may be to use a NoSQL approach. E.g. store the field list in an XSD and use this in your app to have the student fill in a form that you store as XML. It's simpler, and there will be a person looking at the request anyway, so they can point out missing or wrong data.
i'm trying to compare two data sets (vendor masters) from two systems. we are moving to one system, so we want to avoid duplication. the issue is that the names, addresses, etc could be slightly different. for example, the name might end in 'Inc' or 'Inc.' or the address could be 'St' or 'Street'. the vendor masters have been dumped to excel, so i was thinking about pulling them into access to compare them, but i'm not sure how to handle the inexact matches. the data fields i need to compare are: name, address, telephone number, feder tax id (if populated), contact name
Here is how I would proceed. You will rarely get answers like this on Stack Exchange, since your question if not focused enough. This is a rather generic set of steps not specific to a particular tool (i.e. database or spreadsheet). As I said in my comments, you'll need to search for specific answers (or ask new ones) about the particular tools you use as you go. Without knowing all the details, Access can certainly be useful in doing some preliminary matching, but you could also utilize Excel directly or even Oracle SQL since you have it as a resource.
Back up your data.
Make a copy of your data for matching purposes.
Ensure that each record for both sets of data have a unique key (i.e. AutoNumber field or similar), so that until you have a confirmed match the records can always be separately identified.
Create new matched-key table and/or fields containing the list of matched unique key values.
Create new "matching" fields and copy your key fields into these new fields.
Scrub the data in all possible matching fields by
Removing periods and other punctuation
Choosing standard abbreviations and replacing all variations by the same value in all records. Example: replace "Incorporation" and "Inc." with "Inc"
Trim excess spaces from the end and between terms
Formatted all phone numbers exactly the same way, or better yet remove all space and punctuation for comparison purposes, excluding extension information: ##########
Parse and split multi-term fields into separate fields. Name -> First, Middle, Last Name fields; Address -> Street number, street name, extra address info.
The parsing process itself can identify and reconcile formatting differences.
Allows easier matching on terms separately.
Etc., etc.
Once the matching fields are sufficiently scrubbed, now match on the different fields.
Define matching priorities, that is which field or fields are likely to produce reliable matches with the least amount of uncertainty.
For records containing Tax ID numbers, that seems like the most logical place to start since an exact match on that number should be valid OR can indicate mistakes in your data.
For each type of match, update the matched-key fields mentioned above
For each successive matching query, exclude records that already have a match in the matched-key table/fields.
Refine and repeat all these steps until you are satisfied that all matches have been found.
Add all non-matched records to your final merged record set.
You never said how many records you have. If possible, it may be worth your organization's time to manually verify the automated matches by listing them side by side and manually tweaking them when needed.
But even if you successfully pair non-exact matches, someone still needs to make the decision of which record to keep for the merged system. I imagine you might have matches on company name and tax id--essentially verifying the match--but still have different addresses and/or contact name. There is no technical answer that will help you know which data to keep or discard. Once again, human review should be done to finalize the merged records. If you set this up correctly, a couple human eyeballs could probably go through thousands of record in just a day.
Basically, I keep records of client information, and sometimes they will have multiple addresses (properties), e.g.:
id, name, phone, primaryProperty, properties
Considering I cannot create a random number of columns for each entry, I currently just grab the string value from a JavaScript array I create, which is used to hold all of the clients properties, e.g.:
['123 Fakestreet Faketown QC A1A1A1', '555 Falsestreet Falsetown QC B2B2B2']
then I convert it to a string, and then shove it into MySql
"123 Fakestreet Faketown QC A1A1A1, 555 Falsestreet Falsetown QC B2B2B2"
Unfortunately, as cool as arrays are, this makes it so that I can never properly query the above properties individually, unless I echo the value of the column out and use a for loop to change the contents around.
--
I realize that I could probably get away with increasing the total amount of columns on my clients table depending on the maximum amount of properties a client needs, but having a lot of unused fields for all of the other clients is a little strange, no?
I thought about creating a separate table for the properties, but then I would have a problem when it comes to updating the clients information efficiently, and without calling another update.php file. I have a fear of losing internet connection in between updating tables.... if that makes sense.
Normalization is an answer. Just split it into 2 tables. 1st one contains the unique data of the customer (name, shoe size etc.) and the ID. The 2nd table contains the same ID and addresses in the separate rows. Then you just join the tables on the ID column as you need.
Cheers!
G.
I have to develop this database for my work and one part of it is that I have 4 different types of members that need to available to the system: Students, Parents, Mentors, and Coaches. Each have different information associated, so they all have their own table. Another table is a "notes" table that I want to be able to attach and unlimited number of notes to each member.
So for each table, there is a formatted autonumber. For students this number should be S#### in an incremental order. It doesn't matter the number and there will be far fewer than 9,999 students so I'm confident that's all I'll need. Then there's also P#### for parents, and so on.
It needs to be this way because the database also houses survey questions and responses. My notion is that survey responses can be uniquely identified by the member_ID, year, and term taken (since they're only open certain times). The problem is that without the formatted autonumber being found in the query, then ID's will be repeated and non-unique.
So my question is, does format autonumber not work? Am I going to have to use some VBA to build my own autonumbered string that will carry over through queries and other table lookups?
EDIT: So HansUp (below) suggested using a master list that the member tables feed off of. I've set this up since I haven't thought of an alternative. Basically, the flow is this:
Database user clicks "New Student"
"new student" form opens, along with "new member".
"new member" form creates a new ID # and assigns S group, sets viability off
Concatenated ID is then passed to "New student" form
If OK, then all changes are comitted
If cancel, then DoCMD.Undo for both new student and new member.
Would this do it? I'm not exactly sure how to pass that undo statement to the "New member" form though...
Leave the auto-number field as it is. it won't help you even if it does to your current business requirement it will create problem once your application grows further.
Use GUID/UUID to overcome database-level (or even global level) unique ID issues. This way you will maintain an unique ID throughout your database which will help in your case to have only one "notes" table for all of your entities.
in short:
Add a GUID field in your tables
Use triggers or public function/macro to generate the GUID
try to merge students, parents, mentor & coach into one table by separating them by "Type"
Remember an auto-number field is not continuous (in case if some records get deleted the gab will be there)
you can always perform string concatenation/format to produce S12355 number in your query to present it to your end-users.
I guess your main goal is to use only one note table for all of your users. GUID would be the way to go.
here some starting point: How can I generate GUIDs in Excel?
I hope someone can help me with this:
I have a simple query combining a list of names and basic details with another table containing more specific information. Some names will necessarily appear more than once and arbitrary distinctions like "John Smith 1" and "John Smith 2" are not an option, so I have been using an autonumber to keep the records distinct.
The problem is that my query is creating two records for each name that appears more than once. For example, there are two clients named 'Sophoan', each with a different id number, and the query has picked up each one twice resulting in four records (in total there are 122 records when there should only be 102). 'Unique values' is set to 'yes'.
I've researched as much as I can and am completely stuck. I've tried to tinker with sql but it always comes back with errors, I presume because there are too many fields in the query.
What am I missing? Or is a query the wrong approach and I need to find another way to combine my tables?
Project in detail: I'm building a database for a charity which has two main activities: social work and training. The database is to record their client information and the results of their interactions with clients (issues they asked for help with, results of training workshops etc.). Some clients will cross over between activities which the organisation wants to track, hence all registered clients go into one list and individual tables spin of that to collect data for each specific activity the client takes part in. This query is supposed to be my solution for combining these tables for data entry by the user.
At present I have the following tables:
AllList (master list of client names and basic contact info; 'Social Work Register' and 'Participant Register' join to this table by
'Name')
Social Work Register (list of social work clients with full details
of each case)
Social Work Follow-up Table (used when staff call social work clients
to see how their issue is progressing; the register has too many
columns to hold this as well; joined to Register by 'Client Name')
Participants Register (list of clients for training and details of
which workshops they were attended and why they were absent if they
missed a session)
Individual workshop tables x14 (each workshop includes a test and
these tables records the clients answers and their score for each
individual test; there will be more than 20 of these when the
database is finished; all joined to the 'Participants Register' by
'Participant Name')
Queries:
Participant Overview Query (links the attendance data from the 'Register' with the grading data from each Workshop to present a read-only
overview; this one seems to work perfectly)
Social Work Query (non-functional; intended to link the 'Client
Register' to the 'AllList' for data entry so that when a new client
is registered it creates a new record in both tables, with the
records matched together)
Participant Query (not yet attempted; as above, intended to link the
'Participant Register' to the 'AllList' for data entry)
BUT I realised that queries can't be used for data entry, so this approach seems to be a dead end. I have had some success with using subforms for data entry but I'm not sure if it's the best way.
So, what I'm basically hoping to achieve is a way to input the same data to two tables simultaneously (for new records) and have the resulting records matched together (for new entries to existing records). But it needs to be possible for the same name to appear more than once as a unique record (e.g. three individuals named John Smith).
[N.B. There are more tables that store secondary information but aren't relevant to the issue as they are not and will not be linked to any other tables.]
I realised that queries can't be used for data entry
Actually, non-complex queries are usually editable as long as the table whose data you want to edit remains 'at the core' of the query. Access applies a number of factors to determine if a query is editable or not.
Most of the time, it's fairly easy to figure out why a query has become non-editable.
Ask yourself the question: if I edit that data, how will Access ensure that exactly that data will be updated, without ambiguity?
If your tables have defined primary keys and these are part of your query, and if there are no grouping, calculated fields (fields that use some function to change or test the value of that field), or complex joins, then the query should remain editable.
You can read more about that here:
How to troubleshoot errors that may occur when you update data in Access queries and in Access forms
Dealing with Non-Updateable Microsoft Access Queries and the Use of Temporary Tables.
So, what I'm basically hoping to achieve is a way to input the same data to two tables simultaneously (for new records) and have the resulting records matched together (for new entries to existing records). But it needs to be possible for the same name to appear more than once as a unique record (e.g. three individuals named John Smith).
This remark actually proves that you have design issues in your database.
A basic tenet of Database Design is to remove redundancy as much as possible. One of the reasons is actually to avoid having to update the same data in multiple places.
Another remark: you are using the Client's name as a Natural Key. Frankly, it is not a very good idea. Generally, you want to make sure that what constitutes a Primary key for a table is reliably unique over time.
Using people's names is generally the wrong choice because:
people change name, for instance in many cultures, women change their family name after they get married.
There could also have been a typo when entering the name and now it can be hard to correct it if that data is used as a Foreign Key all in different tables.
as your database grows, you are likely to end up with some people having the same name, creating conflicts, or forcing the user to make changes to that name so it doesn't create a duplicate.
The best way to enforce uniqueness of records in a table is to use the default AutoNumber ID field proposed by Access when you create a new table. This is called a Surrogate key.
It's not mean to be edited, changed or even displayed to the user. It's sole purpose is to allow the primary key of a table to be unique and non-changing over time, so it can reliably be used as a way to reference a record from one table to another (if a table needs to refer to a particular record, it will contain a field that will hold that ID. That field is called a Foreign Key).
The names you have for your tables are not precise enough: think of each table as an Entity holding related data.
The fact that you have a table called AllList means that its purpose isn't that well-thought of; it sounds like a catch-all rather than a carefully crafted entity.
Instead, if this is your list of clients, then simply call it Client. Each record of that table holds the information for a single client (whether to use plural or singular is up to you, just stick to your choice though, being consistent is hugely important).
Instead of using the client's name as a key, create an ID field, an Autonumber, and set it as Primary Key.
Let's also rename the "Social Work Register", which holds the Client's cases, simply as ClientCase. That relationship seems clear from your description of the table but it's not clear in the table name itself (by the way, I know Access allows spaces in table and field names, but it's a really bad idea to use them if you care at least a little bit about the future of your work).
In that, create a ClientID Number field (a Foreign Key) that will hold the related Client's ID in the ClientCase table.
You don't talk about the relationship between a Client and its Cases. This is another area where you must be clear: how many cases can a single Client have?
At most 1 Case ? (0 or 1 Case)
exactly 1 Case?
at least one Case? (1 or more Cases)
any number of Cases? (0 or more Cases)
Knowing this is important for selecting the right type of JOIN in your queries. It's a crucial part of the design assumptions when building your database.
For instance, in the most general case, assuming that a Client can have 0 or more cases, you could have a report that displays the Client's Name and the number of cases related to them like this:
SELECT Client.Name,
Count(ClientCase.ID) AS CountOfCases
FROM Client
LEFT JOIN ClientCase
ON Client.ID = ClienCase.ClientID
GROUP BY Client.Name
You've described your basic design a bit more, but that's not enough. Show us the actual table structures and the SQL of the queries you tried. From the description you give, it's hard to really understand the actual details of the design and to tell you why it fails and how to make it work.