How do I move a field to a different table and maintain relationships? - sql

I figure this has to be easy, I'm just not sure how to ask the question.
I have thousands of records I imported from a Excel Spreadsheet in a Microsoft Access table with a field that I want to extract into a new table. How do I move the data from the field in the existing table to a new table and maintain the relationships to the record?
The goal is to move the existing data from the one field into a new table that will have a one-to-many relationship with the existing parent table.
For example, in a table called tblProperties I have the following fields:
Property_Address | Property_Owner | UtilityMeter_Number
I want to maintain a history of utility meters on properties as they are replaced, so I want to move the UtilityMeter_Number field from tblProperties into a new table called tblMeters and create a one-many relationship between the two so I can have multiple meter records for each property record.
How do I move all the existing data from the UtilityMeter_Number field in tblProperties into tblMeters, and maintain the relationship?
What is what I'm trying to do called, and how do I do it?

This is called normalizing data structure.
Use a SELECT DISTINCT query to create unique records. Use that dataset as source to create a new table. Something like:
SELECT DISTINCT CustID, LName, FName, MName INTO Customers FROM Orders;
Now delete unnecessary LName, FName, MName fields from Orders table.
Tables are related on the common CustID fields. An autonumber primary key is not utilized. If you do want a relationship on autonumber PK, then continue with following steps:
add an autonumber field in new table
create a number field in original table
run an UPDATE action SQL to populate new number field with autonumber value from new table - join tables on common CustID fields
also delete CustID field from original table

Related

Sql server, insert data into two tables, populate one before the other

My first post here as I am starting in a new job where my old sql skills already are on the test - I am not advanced user from before either.
I believe there might be some answers here already that might be answering my question, but I am still a bit unfamiliar - both with the forum and more advanced sql syntaxes. Some answers are pretty old as well.
And - please excuse me for any grammatical errors.
Anyways, if anyone might be able to help.
I will be receive huge lists (.csv or similar) with data input.
The datalists will contain fields for type customerdata (name, address etc) and fields for type real estate/property data (street address, buildingIDs etc).
The customerdata and propertydata needs to be put into two separate tables.
My problem is like this:
- The two tables are depended on eachother as in the propertydata table needs to be populated with data first, which will generate a unique GUID - which again will be used when populating the customerdata table - connecting the customer to the correct property/real estate.
The first thing that came to mind is to populate all data into a temporary table.
But I am not quite sure how to loop through each row so I ensure that propertytable is populated first, then the customertable using the GUID.
Get data that involves propertydata and populate the property table
Get the unique GUID generated in property table
Get data that involves customerdata and populate the customer table - with correct GUID
Loop through rest of the set until there are no more rows with data.
I have seen some things like transactions, cursors, output etc that seems to be within my scope, but not sure which would be best way to solve my challenge? Am I near something when thinking like that?
EDIT:
These are example fields that will come as one row in .xlsx/.csv format.
Number of rows in such list will vary from time to time.
Property ID
Property address
Property building ID (only one)
Property established date
...Misc other property related fields
Customer ID
Customer Name
Customer Address
Postal code
...Misc other customer related fields
Fields 1 through 5 will need to populate a property table first. When each row in property table is populated it will generate unique GUID.
Then fields 6 through 10 will be used to populate a customer table, but also need to be populated with the corresponding unique GUID created above in the property table.
Property table:
Property ID
Property address
Property building ID (only one)
Property established date
...Misc other property related fields
UNIQUE PROPERTY GUID (created when populating each new row in table)
Customer table:
UNIQUE PROPERTY GUID
Customer ID
Customer Name
Customer Address
Postal code
...Misc other customer related fields
I suggest you use a staging table.
Load all data into a staging / temporary table and assign GUID numbers to each row.
Copy property details from staging table to property table taking GUID from the staging table
Copy customer details from staging table to customer table taking GUID from the staging table.
Delete data in staging table.
A quick example:
INSERT INTO PropertyDetails( GUID, PropertyID, PropertyAddress, ... )
SELECT GUID, PropertyID, PropertyAddress, ...
FROM StagingTable
INSERT INTO CustomertDetails( GUID, CustomerID, CustomerName, ... )
SELECT GUID, PropertyID, PropertyAddress, ...
FROM StagingTable

Assign unique ID to duplicates in Access

I had a very big excel spreadsheet that I moved into Access to try to deal with it easier. I'm very much a novice. I'm trying to use SQL via Access.
I need to assign a unique identifier to duplicates. I've seen people use DENSE_RANK in SQL but I can't get it to work in Access.
Here's what I'm trying to do: I have a large amount of patient and sample data (20k rows). My columns are called FULL_NAME, SAMPLE_NUM, and DATE_REC. Some patients have come in more than once and have multiple samples. I want to give each patient a unique ID that I want to call PATIENT_ID.
I can't figure out how to do this, aside from typing it out on each row. I would greatly appreciate help as I really don't know what I'm doing and there is no one at my work who can help.
To illustrate the previous answers' textual explanation, consider the following SQL action queries which can be run in an Access query window one by one or as VBA string queries with DAO's CurrentDb.Execute or DoCmd.RunSQL. The ALTER statements can be done in MSAcecss.exe.
Create a Patients table (make-table query)
SELECT DISTINCT s.FULL_NAME INTO myPatientsTable
FROM mySamplesTable s
WHERE s.FULL_NAME IS NOT NULL;
Add an autonumber field to new Patients table as a Primary Key
ALTER TABLE myPatientsTable ADD COLUMN PATIENT_ID AUTOINCREMENT NOT NULL PRIMARY KEY;
Add a blank Patient_ID column to Samples table
ALTER TABLE mySamplesTable ADD COLUMN PATIENT_ID INTEGER;
Update Patient_ID Column in Samples table using FULL_NAME field
UPDATE mySamplesTable s
INNER JOIN myPatientsTable p
ON s.[FULL_NAME] = p.[FULL_NAME]
SET s.PATIENT_ID = p.PATIENT_ID;
Maintain third-norm principles of relational databases and remove FULL_NAME field from Samples table
ALTER TABLE mySamplesTable DROP COLUMN FULL_NAME;
Then in a separate query, add a foreign key constraint on PATIENT_ID
ALTER TABLE mySamplesTable
ADD CONSTRAINT PatientRelationship
FOREIGN KEY (PATIENT_ID)
REFERENCES myPatientsTable (PATIENT_ID);
Sounds like FULL_NAME is currently the unique identifier. However, names make very poor unique identifiers and name parts should be in separate fields. Are you sure you don't have multiple patients with same name, e.g. John Smith?
You need a PatientInfo table and then the SampleData table. Do a query that pulls DISTINCT patient info (apparently this is only one field - FULL_NAME) and create a table that generates unique ID with autonumber field. Then build a query that joins tables on the two FULL_Name fields and updates a new field in SampleData called PatientID. Delete the FULL_Name field from SampleData.
The command to number rows in your table is [1]
ALTER TABLE MyTable ADD COLUMN ID AUTOINCREMENT;
Anyway as June7 pointed out it might not be a good idea to combine records just based on patient name as there might be duplicates. Better way will be treat each record as unique patient for now and have a way to fix patient ID when patient comes back. I would suggest to go this way:
create two new columns in your samples table
ID with autoincrement as per query above
patientID where you will copy values from ID column - for now they will be same. But in future they will diverge
copy columns patientID and patientName into separate table patients
now you can delete patientName column from samples table
add column imported to patients table to indicate, that there might be some other records that belong to this patient.
when patients come back you open his record, update all other info like address, phone, ... and look for all possible samples record that belong to him. If so, then fix patient id in those records.
Now you can switch imported indicator because this patient data are up to date.
After fixing patientID for samples records. You will end up with patients with no record in samples table. So you can go and delete them.
Unless you already have a natural key you will be corrupting this data when you run the distinct query and build a key from it. From your posting I would guess a natural key would be SAMPLE_NUM. Another problem is that if you roll up by last name you will almost certainly be combining different patients into one.

decompose source data into new, many-to-many schema

I am using MS Access 2010 to do some transformations of data. Specifically, I need to create the data structure for a many-to-many relationship between concept (summarized by rxnconso.rxcui) and word (summarized by drugwords.id. Note that each value of drugwords.id needs to correspond with a unique value of name from the words table in the images below.). To accomplish this, I need to create two tables, drugwords and drugwordsConsoJunction, and also decompose the contents of an existing table words into the drugwords and drugwordsConsoJunction tables. The structure of the destination tables is:
drugwords table: (this table needs to be created)
id (autonumber pk needs to be created from distinct values of words.name)
name
drugwordsConsoJunction: (this table needs to be created)
word_id (fk to drugwords.id)
rxcui (fk to rxnconso.rxcui)
rxnconso (this table already exists):
rxcui
...other fields
The source table for this transformation is called words and has two columns; a value for rxcui, and a value for name. As you can see from the images below, there can be many name values for a given rxcui value. And the second image below shows that there can be many rxcui values for a given name value.
How do I write the SQL to transform words into drugwords and drugwordsConsoJunction, as per the above specifications?
I have uploaded a copy of the database to a file sharing site. You can download it at this link.
If the proposed [drugwords] table is already going to have unique values in its [name] column then you don't need an AutoNumber ID column, you can just use the [name] field as a Primary Key. In that case, the table that maps "words" to the corresponding [rxcui] values could be created by simply doing
SELECT DISTINCT rxcui, [name] INTO drugwordsConsoJunction FROM words
Then you can use the "words" themselves instead of introducing another layer of mapping from (distinct) "words" to (distinct) "IDs".

Linking or Mapping two tables together

Consider my data as inventory list separated by categories.
When I started I had one table that should have been split into two tables, else in the oldTable the columns in a given row would have been un-related. I have created two new tables in my database, one for categories and the other for data/items. Now I am trying to use the oldTable existing data to fill the newTable data/items table so I can learn SQL and not have to manually do it. The categories table I filled in manually because I could not see how to do it otherwise.
The old table has:
tableName (
id,
categoryA,
categoryB,
categoryC,
categoryD,
categoryE,
categoryF,
isPriorityA,
isPriorityB,
isPriorityC,
isPriorityD,
isPriorityE,
isPriorityE
)
The new tables have:
Categories (
cat_id,
name
)
dataItem (
item_id,
cat_id,
name,
priority,
description,
URL
)
How do I force the new dataItem table to require the cat_id match one of the values in the Categories.cat_id table column? Perhaps to give an error if a value is added outside of the range? I believe this may be mapping or linking tables, to thereby make them relationship tables.
How do I copy the tableName data to the dataItem table one column at a time in alphabetical order bringing the name,priority with it and allowing it to auto-increment the item_id value?
Sounds like you want to use a foreign key to limit dataItem.cat_id to values in Categories.cat_Id. Something like this:
ALTER TABLE dataItem ADD FOREIGN KEY (cat_id) REFERENCES Categories(cat_id);
Exact syntax may depend on which database you are using. For more info on foreign keys see: http://www.w3schools.com/sql/sql_foreignkey.asp

MS Access 2007 - Semi-Autonumber

I am building my own CRM access database that will contain a list of contacts. I would like to have an opportunity reference one contact as an employee, and another as the customer. Is there a way that I can add employees using their internal user ID (always 4 digits) and autonumber customer contacts?
I don't plan on building forms until I am comfortable that everything is working properly in table view.
You cannot assign an ID to an autonumber field. I might suggest adding an employeeID field to your contacts table that would have the employee ID number. The contact ID would still be an autonumber, so in essence they would have two IDs, but their employeeID would need to be stored in a different field.
You can try something different, but you will likely run into a duplicate ID at some point. Use a seperate table for autonumber Customer IDs. When adding a customer into your contact table, you "insert" a new record into the separate customer ID table to get the autonumber ID. If you're inserting an employee, just use the EmployeeID as the contact ID. So you need to be very careful when mixing two ID systems. It's best to use 1 ID and then use the other ID in some other field.
Consider using two tables, one for contact fields and another for employee-specific fields. Put your AutoNumber field in the contact table, and put the employee id in the employee table. In the employee table, use a foreign key that refers to the AutoNumber field in the contact table.