Please pardon my ignorance, I'm new to spatial data. I've been tasked with creating a map report in SSRS. When finished, the report will show locations of stores participating in the same promotion.
Currently, my database doesn't contain this information, so I have to create a table first. Luckily, I have a spreadsheet that does contain this information, so I can just import it. However, I'm not convinced that my spreadsheet has all the information I need. It shows basic information such as store name and address, but no geographical information (which I'm assuming I need).
So my question: What kind of data does a SQL table need in order to build a map report in SSRS?
You can create a custom table with the specific information that you want, but there are an inportant information that you mustn't forget, for example:
From the spatial data source:
SpatialData - A field that has spatial data that specifies the latitude and longitude of the city.
Name - A field that has the name of the city.
Area - A field that has the name of the region.
From the analytical data source:
Population - A field that has the city population.
City - A field that has the name of the city.
Area - A field that has the name of the territory, state, or region.
Related
I am really new to Tableau.
I have an "accident" table (excel) that describes each traffic accident in the past few years, including its "district" (location). I have another "district" table that describes each district of the city, including its population.
Now I want to join those two tables and create a graph of accidents per person for each district.
The problem I face is: The two excel files are from different databases, which means that the same district may appear to have different names in two tables. How do I let tableau know the matching between districts?
Could you tell me how I can join those two tables so that I can create my chart?
Please let me know if there are any problems with my approach or understanding. Thank you in advance!
Assuming I understand question correctly.
Your accident transactions might have..
District#1, Accident Date, ,
District#2, Accident Date, ....
District#3, Accident Date, ....
Your district dimension table has 1 unique record per district, but names don't match.
District1, CityName
District2, CityName
District#3, CityName
You want to combine the results correctly...
Excel is the preferred datasource?
I assume the actual sources of data do NOT have a singular "code" value for the district name that actually does match. This is where MDM is important for system integrations. Right answer IMO is to actually have source systems/dbms understand that they are integrated and create XREF in 1 system that is required when a district is setup or exists.
Options. I think you need to "clean" the data someplace. The question is where.
MDM in your source system integrations.
Are the excel sources created in automated fashion? You could create a manual XREF excel sheet and lookup/decode one of the district values to conform a single definition of the district. In addition to your graph. create an audit that looks for any new data that doesn't "lookup" correctly to know to maintain the manual XREF.
Probably could create calculated XREF is tableau calc itself and then blend based on that calculated field. I think that would require full desktop versus web editor.
Tableau Prep might help as well. (although my company doesn't use this)
I would like to be upfront. I am by no means an expert or even really all that technologically savy. However, I inherited a training system where the only way to find out if someone was current was to dig through physical file cabinets and try to find the hard copy. I have put together a basic access database to try and improve the situation. It is working okay, but I've run into a problem.
Previously, most training occurred in small enough batches that data entry is not a problem. (No more than 15-20 entries at any one time). However, regulatory changes now mandate the company put everyone through a mandated training course annually. This means all information about the training will be identical, except for the employee ID associated with the record.
Right now I can manually enter this training just like any other, but I have to perform this nearly identical data entry for each of the several hundred employees in the company.
I would like to be able to enter the pertinent details about the training and then have access create an training record for each employee.
The current form asks the user:
Who is the employee that was trained? (The appropriate employee ID # is entered)
Which subject was trained on? (the appropriate selection is made via combo box)
On what date was the training completed? Date picker is used to fill.
What is the file path to the scanned training certificate? (The majority of this field is prepopulated so only the actual file name needs to be typed. For the specific training in question all the employees of the company will be included in the same scanned pdf. Subsequently, this filed will be identical for all employees.)
The fields on the current form are:
txtEmpID – Text box, where employee ID # is entered. Corresponds to
field "empID"
cboTask – Combo box, where the appropriate training
subject is selected. Corresponds to field "reqID"
txtDate – Text box, the date the training was completed.
Corresponds to field "trngDate"
txtFilePath – Text box, file path to the scanned pdf of the physical
training record. Corresponds to field "trngLocat"
I would like to be able to fill in the information for 2-4 but then have access create a record, for each employee in my employees table, where all the data from 2-4 is identical.
Is this possible?
Pertinent Tables:
tblEmployees – keyed on field “empID” which is the employee number.
tblTrngSubjects - Keyed on field "reqID" which is autonumber.
tblTrngRec – keyed on field “recordID” which is autonumber. Relates
to tblEmployees through field “empID”. Relates to tblTrngSubjects
through field "reqID".
tblTrngRec is the table in which the records will be stored.
Other information that may be relevant:
I am using Access 2016.
I once had a copy of Access 2010 the missing manual…but that was in 2010. It has been almost a decade since I did anything more advanced than “docmd.openform”
I greatly appreciate any and all advice. Thanks, in advance.
I admit I haven't worked with access in quite some time, so some of the syntax might be slightly off. You need to know a list of employee IDs that were in that training.
Insert into tblTrngRec(empID,ReqID,txtDate,txtFilePath)
select empID
,25 'You need to enter this manually
,"6/9/2020" 'You need to enter this manually
,"Enter your file path"
from tblEmployees
where EmpID IN (enter a comma delimited list of employee IDs)
I have a two numeric fields one is called Lat and the other is called Long (see the attached image). When tableau reads the data, it assigns the geo role (as indicated by the data symbol) to the field of Lat but not the Long field. Is there a way I can make Tableau AUTOMATICALLY assign the geo role to the field of Long too?
I understand that I can always manually switch a field to the geographic data type or used the field of Longitude (generated). However, for my particular task on hand, it is best I can just use the field of Long as geographic data automatically.
If this information helps: The original dataset is based on a Txt file. The Lat and Long field in the original Txt file are String datatype, they were then transformed to Double in an ETL software.
Any help would be greatly appreciated!
Name your field Longitude instead of Long, and Tableau will automatically assign it the appropriate geographic role.
You might want to then also use Latitude instead of Lat for consistency.
I need to implement a feature where the user will be generating reports dynamically.
In that feature, the user will be presented with an interface to select some specific modules. Each module will point to a set of tables internally.
Consider the following tables,
**Table Name : module_location**
location_id
location_name ->Contains a location name
**Table Name : module_streets**
street_id
street_location_id (F.K module_location.location_id)
street_name ->Contains street name in a location
If the user selects the module name Location, he is indeed choosing the list tables to be queried on(which is done internally)
In this case, module_location and module_streets (They will be joined by location id).
After selecting the Location module the user has to choose the set of fields which needs to be shown in the dynamic report, once generated.
So he'll be provided with an interface to select those fields. The names given in the interface will be alias names for the respective fields in the tables
ie,
The user will be presented with option to select the following
Location Name -> Corresponds to the field 'location_name'
Street Name -> Corresponds to the field 'street_name'
After selecting the required fields to be shown, the user will have to select some conditions like(count,sum etc)
Suppose, the condition is like Get the number of streets in a location, the user will have to add condition count against the option Street Name.
After selecting the conditions, the user have to simply click the submit button in-order to generate the report.
The issue I'm facing here is how to decide the columns to be grouped. If this is done manually, I know that I need to group the location_id to get the count. So how can I do that, if the query is generated dynamically?
Kindly help. The database I'm using is postgresql8.4
So I have a form I have Vendors fill out when they want to ship to us. It's an excel form that I then import into Access so I can run reports. Sometimes when they send the form back it's in a format in which I have to manually enter the data into our database.
The form looks like this:
The middle section is just for example purposes so it's a rectangle with text in it.
So everything seemed simple enough until I got to the middle section. See in my excel form I have a section for multiple PO's and units. So essentially each shipment can have one to many PO's and Units. Currently I can approach this task with the redundant method of reentering information per PO on the form. But I want to make this simple.
So the task at hand is that I want to have a form field for PO's and Units where I can input multiple lines of information so that when I hit a submit button. It appears in the database on separate lines with the same vendor information.
So if I filled out my form had this in the middle section:
PO | Units
111111 22
222222 33
333333 44
When I hit submit I want it to attach the rest of the forms information to each PO on separate lines so it'd be like:
Vendor | City | State | PO | Units
Nike Memphis TN 111111 22
Nike Memphis TN 222222 33
Nike Memphis TN 333333 44
So how would I go about accomplishing this task?
From your description of the problem and your example of how the data appears to ultimately be stored in Access it looks to me like you are using Access as a spreadsheet and not as a database. This is ok, but you might want to consider normalizing the data to take advantage of the power of databases in general.
For example:
Create a Vendors table whose sole purpose is to keep details about each Vendor you work with. A very basic implementation would have an ID field to uniquely identify each vendor and a Name field for the vendor name.
If Vendors will only ever have a single location you could also store City, State, ZipCode and Email in this same Vendor table, but I suspect having a separate VendorLocation or VendorAddress table would be a better fit long term.
Create a VendorShipment table that tracks the higher level information on your mockup, such as:
ShipmentID (primary key of this table)
VendorID (foreign key back to Vendor table)
Ready Date
Carrier
Estimated Cost
FreightClass
Tracking #
Estimated Transit Time
Finally, create a VendorShipmentDetail table that tracks the information of each shipment, including:
ShipmentDetailID (primary key of this table)
ShipmentID (foreign key back to VendorShipment table)
PO
Units
Any other details that you want to or need to track
Organizing and storing the data in a normalized fashion would ultimately help simplify your data entry \ data management process and potentially make for a better user experience.
For example, rather than having to enter the Vendor Name, Address information, etc. each time you could instead use a combo box control that is tied to the Vendor table. If the Vendor exists in the table you select it from the list and you already have the Address information, no need to re-enter it each time. If the Vendor did not already exist you enter it once (probably on a Vendor screen where you maintain the details for each Vendor) and draw upon the information in the future.
You would then use queries to tie the information back together for reporting purposes (de-normalize the information).
The art of database design can take a while to pick up, but a good starting point might be to check out the Northwind database that Microsoft has maintained over the years. It has some examples you could draw from immediately to get a practical understanding of how to use normalization within Access. You can find more information here: http://office.microsoft.com/en-us/templates/northwind-sales-web-database-TC101114818.aspx