In my Geoserver instance, I've created two layers:
A layer that references a Shapefile that contains the polygons of the cities in Brazil. Each city has a unique id.
A layer created from a database store via a "SQL View" (a Geoserver one, not a database SQL View) that maps the unique id of each city to an aggregate value (eg the number of registered users in the city).
I need to style the polygons from the first layer according to the values present on the second layer. Is it possible? I know I can import the geometries into my database, but it makes things very very very very slow.
Related
I'm working on an entity relationship diagram , trying to outline an initial structure for a database I'm planning to build in Oracle SQL Developer.
In one part of my database there are two camera entities which take images and send them to another entity called a Field Programmable Gate Array to be processed. Now working out the relationship between these entities there are a number of many to many relationships that occur between these entities.
These are the two camera entities:
These Camera generate images, now conceptually many of these two cameras can create many images, so that is defined as a many to many relationship.
Here is the table I created to link the PK from the MastCam table to with the PK from the MastCam_Images table
As you can see, this table highlights which of the two MastCams created the specific image related to it
This table highlights the images generated and their specific resolution
At this point, the images are sent to the FPGA to be processed. Again conceptually, many images in this table can be processed by many of the two FPGA's that are present in the FPGA table.
At this point the FPGA outputs the processed images
My main issue here, is that once the images are passed to the FPGA, I lose track of what specific Mastcam images were processed into which specific FPGA processed image.
Would anyone be able to provide a logical solution to my issue?
P.S I'm sorry for inconsistent sizes of the images
You want rows where "mastcam image mi was processed into processed image pi". That table is not expressible in terms of your other tables. So add it. But then your table FPGA/FPGAPI holding rows where "fpga f output processed image pi" is expressible in terms of the other tables, since it is also rows where "for some mi [mastcam image mi was processed into processed image pi AND mastcam image mi was processed by fpga f]", which is a projection of the join of the new table & table MIF/PGA.
In the relational model relations/tables represent business/application relation(ship)s/associations. A table holds the rows that make a true proposition (statement) from some predicate (statement template) that for base relations is given by the designer and for queries is built from base table predicates & relation operators. The designer must find sufficient predicates/tables to record all data of interest while hopefully minimizing complexity & redundancy.
A cardinality is just one property of a relation(ship)/association. A FK (foreign key) constraint (although incorrectly called a "relationship" by pseudo-ER methods) is just fact of a certain kind about a pair of tables.
Time to read a book on information modeling, the relational model & database design.
I am new to databases and sql and would like to design a database for a fitness app that will keep track of workouts at the gym.
In my app, I have designed a custom workout object that has a name (e.g. 'Chest day'), an ID (some number) and a date (string). Each workout object contains an array of exercises, another custom object, that has a property for called 'set'. The set is also a custom object with only two numeric properties: number of reps and weight (e.g. 10 reps at 50 lbs)
What I thought of is to have one table for the workouts, another for the exercises and another for the sets. The problem is I do not know how to connect the tables (i.e. link multiple exercises to a unique workout and link multiple sets to a unique exercise) and am not sure if this is even the correct approach.
Also, I planned to set up the backend for this app using the amazon web services mobile hub which provides a noSQL database.
In NoSQL, you should keep all the attributes in single table. You shouldn't normalize the data like RDBMS. Also, please try to come away from Join. The main advantage of NoSQL is that keep everything as one item, so that you don't need to Join to get the result.
Advantages of this approach are:-
1) Fast response as all the data is present as one item in a table
2) Schema less database i.e. you can add any attributes at any time (i.e. no need to alter table and add the new columns)
DynamoDB design for above use case:-
The combination of partition and sort key should be unique
name -String (Partition Key)
id -Number (Sort Key)
date - String
exercise : [array of values] - List data type
custom_set : {rep : 1, weight : 2} - Map data type
Important Note:-
The important thing while designing the data model for DynamoDB is all the data retrieval use cases (i.e. Query Access Patterns) should be available to design the appropriate model.
I want to represent a network using a relational schema.
The entities of my network are:
Node : a point on the network.
Arc : a direct connection between 2 nodes
Path : an ordered sequence of arcs.
Is a relational model suited for representing such a network ?
I am considering SQL/No SQL as the options.
The size of my data is not expected to grow at a very rapid pace. I do not want to pick SQL/No SQL based on any predefined query patterns.
Often the best tool to represent a network is a graph database like Neo4j.
But when you want to do it in SQL, both Node (or Vertex in graph theory) and Arc (properly called Edge) would get an own table. A Vertex would contain only the data about the vertex itself, and no information about its relations to others. An Edge would contain the primary keys of the two nodes it links, plus any meta-information about the link itself.
When you need to store paths of multiple nodes, you should use two tables. A Path table with the path-id and any data about the path as a whole, and another table PathVertex consisting of Path-ID, number in that path and primary key of the Edge table which contains all the positions a path consists of.
I have three tables, one fact and two dimensions. I want to make a referenced relationship between the fact table(measures) called InternetSales and the Geography table, se image(schemaCubeStructure".
The intermediate table is Customer. I first create the Geography and InternetSales tables and then the Customer with a field from Geography to use later when creating the ref. rel.
Everything works fine until browsing the data in the cube (se image "errorBrowseSalesCube". If i don´t make the relationship between the two tables i get image "correctBrowseSalesCube" which is what i want. That is i don´t get any data when processing with the rel.ref.
See image "dimensionUsageSalesCube for rel.ref.
Why is that i don´t get any data?
correctBrowseSalesCube
errorBrowseSalesCube
dimensionUsageSalesCube
schemaCubeStructure
What fields did you use when setting up your reference dimension relationship between Georgaphy and Internet Sales?
The in the AdventureWorksDW database, the Georgaphy dimension is a snowflake off of Customer dimension. In the AdvWrks cube project, Microsoft includes the geography table and corresponding attributes in the customer ssas dimension (red boxes in screenshot below). However, they could have, as it looks like you are trying to do, simply added the GeographyKey to the customer dimension (red arrow in screenshot below)
This exposes the GeorgaphyKey field when creating the reference dimension relationship so that you can properly define the relationship between the intermediate dimension (customer) and the reference dimension (geography):
After that, you can properly browse the Internet Sales facts by Georgraphy dimension attribute (and user) hierarchies:
The correctBrowse sales cube can be easily explained. It means that the data is not calculated based on the Geography dimension and thus indicates that the connection between the Internet sales and the Geography is not correctly calculated.
I would suggest the following:
Try making the customer a Mesaure (or fact table). Do not rename it just make a measure i.e. the count of customers (can be used as a counter of customers/per region or can be invisible altogether).
Then The customer will appear as a measure in Dimension usage and then connect Geography to Internet sales via a many to many relation Using the customer measure table.
I have designed a relatively simple data warehouse that uses the star schema. I have a fact table with just a primary key along with CompanyID and Amount (the actual measurement) columns. Of course I also have a dimension table to represent the companies which the fact table references.
Now I'm required to create a single level hierarchy (CompanyGroup) for companies. This seems like an easy task but the catch is that a single company should be allowed to exist within multiple CompanyGroups.
I experimented with this by creating a new dimension table called CompanyHierarchy that holds a primary key, GroupKey and CompanyKey. Defining a user defined hierarchy where GroupKey is the top level and CompanyKey is the second level yields A duplicate attribute key has been found error for the CompanyKey attribute while processing the dimension.
So, I'm not quite sure how to even start with this. How can I create a user defined hierarchy within a dimension where attributes can exist multiple times?
Screen shot of my current cube definition can be seen at:
img132.imageshack.us/img132/6729/ssasm2m.gif
You need to create a many-to-many relationship (one company can belong to many groups and one group can have many companies) There is an example of a many-to-many relationship in the Adventure Works cube around the sales reason dimension and there is an extensive white paper here that explains a number of different ways of using many-to-many relationships.
There is also a technique for supporting multiple members in the one hierarchy that I documented here