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.
Related
I'm trying to figure out the best way to store graph data structures in an SQL database. After some research, it seems that I can store graph Nodes in a table and just create a join table with the many-to-many relationships between them which would represent the edges (or connections). That seems exactly what I was looking for, but now I want to introduce the users who own the nodes.
From the performance point of view, would it make sense to create a new join table userNodes, or just save users as nodes assuming that node is a generic structure? And what are the implications of storing everything in a single table?
If you have individual attributes that should be stored on a per-node level, then those attributes should be in the nodes table. That is what the table is for.
If the attributes are really a list, then you would want another table. For instance, if multiple users could own a node, then one option would be a userNodes table. However, as you describe the data, there is only one user per node.
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 was wondering how one would represent relationships in Aerospike? I realize it's a Key-Value store but is there an example that can be given?
For example: If have a user in the system and I want to get a list of Thing records associated with that user.
Couple of quick ideas:
1- Have each user be a record (equivalent of a row for conventional RDBMS) with multiple bins, each bin having the Primary Key of a 'Thing' Record in it. You can find more details about Aerospike's data model here. This should work well if the number of Things associated to a user is fairly low (under 100 typically).
2- If you have a large number of 'Things' record associated per user, you could potentially use an LDT (Large Data Type) like an LLIST.
Hope this helps!
One way NoSQL key-value stores diverge from the relational way of thinking is that many-to-one relationships can be represented in the same table using lists and maps.
For example, if your user has several credit cards, each of which is a tuple of (card type, last 4 digits of the card, the token from the processor representing the card, billing zip code) those can be present as a list of maps. JOINs between two tables representing a many-to-one exist because an RDBMS models atomic data, where in Aerospike that data would be modeled as a complex data type.
I have the database:
Node(nno,color)
edge(eno,head,tail,weight,gno)
graph(gno,gname)
bold here represents primary key
and the graphh is directed: head -> tail
how can I build a trigger to check whether or not , with each insert of a node to the graph , the graph is connected? meaning there is a path between every two nodes
How do I even check if there is path between each two nodes ?
I am using postgreSQL
This is an X-Y problem, and most likely unworkable using a trigger: If referential integrity is to be maintained with foreign keys (definitely desirable) then by definition the insertion of a node will create a disconnected graph, and be rejected.
The solution is to have a stored procedure through which all inserts to all three tables are passed, and which only accepts connected graph additions.
Given the assumption that a given graph is already connected, then for an extension to a given graph to be accepted it is sufficient for every node in the extension to be connected to any one node in the existing graph.
I'm trying to store the data in a binary space partitioning tree in a relational database. The tricky part about this data structure is it has two different types of nodes. The first type, which we call a data node, simply holds a certain number of items. We define the maximum number of items able to be held as t. The second type, which we refer to as a container node, holds two other child nodes. When an item is added to the tree, the nodes are recursed until a data node is found. If the number of items in the data node are less than t, then the item is inserted into the data node. Otherwise the data node is split into two other data nodes, and is replaced by one of the container nodes. When an element is deleted, a reverse process must happen.
I'm a little bit lost. How am I supposed to make this work using a relational model?
Why not have two tables, one for nodes and one for items? (Note that I used the term "leaf" instead of "data" nodes below when I wrote my answer; a "leaf" node has data items, a non-"leaf" node contains other nodes.)
The node table would have columns like this: id primary key, parentid references node, leaf boolean and in addition some columns to describe the spatial bounaries of the node and how it will/has been split. (I don't know if you're working in 2D or 3D so I haven't given details on the geometry.)
The data table would have id primary key, leafid references node and whatever data.
You can traverse the tree downward by issuing SELECT * FROM node WHERE parentid = ?queries at each level and checking which child to descend into. Adding a data item to a leaf is a simple INSERT. Splitting a node requires unsetting the leaf flag, inserting two new leaf nodes, and updating all the data items in the node to point to the appropriate child node by changing their leafid values.
Note that SQL round trips can be expensive, so if you're looking to use this for a real application, consider using a relatively large t in the DB constructing a finer-grained tree in memory of the leaves you are interested in after you have the data items.