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.
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.
The relationship I wanna model goes kinda like this:
A master TextResource object that stores high level shared non-localizable data, like maximum length.
One single detail object we can call SourceText, that needs to be tracked separately.
The rest of detail objects, that we can call TargetText.
Both Source and TargetText objects store a string localized in a particular language, along with other localization data.
But the string stored in SourceText is the original one and hence, even if the data schema is the same, they're not functionally equal and this piece of data needs to exist and be unique per each TextResource master object.
And the options I've thought of are:
Regular master-detail tables, but store the SourceText ID in the master table... Potentially creating a circular reference?
Regular master-detail tables, but add a flag/category column to the detail table that marks a row as Source or Target... Though this could potentially lead to having more than one "Source" detail per master and could make querying for the Source data less straight-forward
Store the Source data in the master table, even if this means having similar columns on both master and detail tables (and screwing normalization while at it)
Create three different tables: master, main and detail. Master (TextResource) and main (SourceText) would have a 1-to-1 relationship while there could be n detail (TargetText) rows per master, but other than that the Source and Target tables would share most of their schema
I see benefits and potential problems on all four approaches, so maybe you could lend me a hand deciding one?
What I want to achieve would boil down to:
Have one, and only one, Source string per Resource
Be able to query Text Resources and their Source strings easily and fast
Be able to query the localized strings of a given Resource, including the Source one, easily and fast
Be able to store versioned data of each localized string, including the Source one
And of course, avoid bad practices and observe normalization
Thanks in advance :)
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.
This is a bit of a complex one, and even trying to think it over is somewhat confusing.
Basically I'm having to design a series of tables that will house information about many different pieces of electrical equipment. The arrangement of this equipment is quite complex, and can vary fairly drastically.
The different types of equipment are as follows:
RDC - Remote Distribution Center
EBD - Electrical Bus Duct
UPB - Upright Panel Board
PDU - Power Distribution Unit
Now the way these units work together is slightly confusing as well.
PDU - Powers RDC's, EBD's, and UPB's. They are often redundant, and have a secondary
unit that powers the same equipment in the event of a power failure.
Can also contain breakers and power equipment directly.
RDC - Powers nearly all the equipment on the data center floors, are usually redundant.
They have two units side by side, being powered by a PDU. In the event of a
failure, the second RDC is activated and resumes operations.
EBD - Nearly identical to the RDC, being phased out, but still needs to be tracked in a
similar fashion.
UPB - Similar to an RDC, however, they are not redundant.
Now what I'm trying to do is figure out the most simplistic method of tracking this crazy relationship between all the different items?
I need to track the redundant sources for all possible hardware, but also what powers each unit. This can be quite complex because if two PDUs power a set of two RDCs, we need to be able to track exactly what goes where.
Any idea on exactly where to start?
EDIT Here is a visual representation of what I'm after. The objects that are touching are redundant, and must be documented as such. Also, the different hardware that is connected to each device must be cataloged.
Set up one table for equipment, one table for power supplies, then a third table that matches a piece of equipment with its power supply.
This sounds like a job for an entity-relationship model. You can learn more about that here: enter link description here
But, in the interest of answering your question, here's how I would set it up. I believe I understand the relationships between entities. My shorthand follows this pattern: Table [TableName] ([columns]). I tried to name them so they make the relationships obvious.
Table RDC (id)
Table PDU (id)
Table UPB (id, PduId) // Many-to-one relationship between UPBs and Pdus
Table PDU (id)
Table PDU_RDC (PduId, RdcId) // represents many-to-many relationship between PDUs and RDCs
Table PDU_EBD (PduId, EbdId) // represents many-to-many relationship between PDUs and EBDs
Good luck!
Instead of focusing on "entities" focus on basic facts. Each gives a table or view.
Some of the basic facts just involve entities; others are about (ids of) entities:
RDC(id) // id identifies a remote distribution center
powers(pid,rid) // PDU pid powers RDC rid
backup(rid1,rid2) // RDC rid1 is backed up by RDC rid2
active(rid) // RDC is active
Until you supply adequate statements you want to make/use we can only answer you with guesses or principles; give statements and business rules we can suggest alternatives and rearrangements.
When you get AND between two statements you already have, the table with that statement is expressible as a JOIN of the two statements' tables.
You can introduce notions like hardware type but the tables/statements for that way will involve simpler statements (for which you may have defined tables). The former tables/statements are joins of the latter, and the latter are projections of the former. This means you can write views of either way in terms of the other. Neither is more complex; you have fewer things with more parts or more simpler things. Queries involving given statement will be simpler--but using the appropriate view neither is more complex. However, each way has corresponding versions of constraints and SQL might make certain constraints hard to express declaratively. Investigate join performance later as a non-premature optimization.
When a column is a function of a set of columns there is an FD from the set to the column. A column set forms a key when all other columns are functions of it but of no subset. FDs and keys are kinds of constraint.
There will be certain constraints that a projection of a source table is always a subset of a projection of a target table (maybe the same one). That's an IND. Informally it means something(c1,...) IMPLIES otherthing(c1,...). Formally, EXISTS x1,... t1(c1,...,x1,...) IMPLIES EXISTS y1,... t2(c1,...,y1,...). If the target projection' columns form a key in its table, there's also a FK. SQL FK [sic] declarations actually declare INDs.
There will be other constraints.
Supplying whateever-to-whateverness for a table is just one property about it. Not being 0-or-more-to-0-or-more means a corresponding FD or IND holds. People talk about "a" "1-to-n" "relationship" between entity types or tables but that's just sloppy unclear expression of some constraint. Make sure you know exactly the table(s) and constraint(s) that means.
Read about ORM2 (or NIAM or FCO-IM) because it is based on relational principles (although could be moreso).
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.