I have two object types in Foundry.
Object A
Object B
Both objects have property Y but property Y is not the primary key of either of these objects.
Is it possible to create a link between these two objects without creating a transitive object?
Semantically links in the ontology represent explicitly stating that two objects are related, so the links must identify pairs by their primary key values.
Like you say you can create a transitive object or create a mapping table dataset and a many-to-many link type.
Related
I have not used access for many years, but need what I thought was a simple DB and struggling at early stage.
I have a table that represents objects that can belong to multiple systems and may have some different attributes between the systems.
So my initial idea was to have a table for Systems, a table for Objects, and a child table for Object Attributes.
My Objects table currently is 3 fields:
Key : Autogenerated
Object Name : Text
System : Lookup to system table
Object Name will not be unique as it can appear in multiple systems, so I want to create a unique compound key of the Object Name & System field. This key will be what joins this table to the child Object Attributes table.
My problem is that the System lookup field does not appear in the available fields to use when trying to create a compound key.
Could someone tell me where I am going wrong?
This might not even be possible to do. I have one table that contains items. (item_id, item_name, description, json for deserializing into an actual object)
My second table contains packages. (package_id,package_name,price,description,item_list(2D array))
The 2D array needs to match item_id values to quantities.
Normally, I would simply serialize a JSON array to the item list spot. I worry about item_id values being removed or changed though. I cannot use a foreign key to have a change "cascade" or "delete" child values. Is there a way to store a kind of sub-table in a mysql row?
Let me know if my problem description is not clear. I want to make sure it is followable for anyone else who is trying to find an answer. I might include some images later if it will help.
Solution: No, there isn't a way to store a 2D array in a MySQL row. You have to use a bridge table. Oh well, at least there is a solution. A solution always exists.
Well you can always store 2D array in a column of a database but there is a problem with it, i.e retrieving data from mysql you'll have to parse that column and that column of yours will contain multiple values. When you have a multivalued attribute in your table it must be migrated to another table to normalize your database design.
In your case you are looking at many-to-many relation ship i.e a package may have many items and an item may be taken by many packages. To solve many-to-many relation you have to introduce a new table usually called a Bridge table. that bridge table will take Primary Keys from both item and package tables as Foreign Keys. The reason you add this table is to remove redundancy and that is one of many things normalization is offering.
What you are looking for is called a many-to-many relationship. Usually you create an extra table that creates a map between the two tables. Here is one example:
Many-to-many relationships examples
I was able to store a 2D array as a JSON object by using the index of the second dimension as a key. Here's an example of a 12 x 4 array:
{"0": "[0,0,0,0,0,0,0,0,0,0]", "1": "[0,0,0,0,0,0,0,0,0,0]", "2": "[0,0,0,1,0,1,0,1,0,0]", "3": "[0,0,0,1,1,1,1,1,0,0]"}
I'm trying to understand entities, tables and foreign keys. I have the following:-
AnObject - I have identified this as an entity type.
ID (Primary Key)
Description
State
DependsOn
Creator
Now State has only two values it can be [Alive, Dead]. However it could possibly have another in the future. It can however only be one or the other but it will likely change between the two.
Question:
Should State be its own entity type? Would it be an entity type or
just a table? Should State have a foreign key to AnObject or vice
versa? EG
State
ID (PK)
Description
AnObject_ID (Foreign Key references AnObject)
Question: The DependsOn attribute of AnObject can have multiple values of other AnObject entity types. Obviously a field cannot have multiple values but I'm not sure how to model this?
The Creator attribute of AnObject also takes up a strict number of values [Fred, Jim, Dean]. Should I have an entity type (table) for a Creator with a foreign key to AnObject ID? So, A Creator can create, 0, 1, m AnObjects but AnObject can only have one creator?
Thanks,
State could just be an enum field, unless you need users to be able to add other State values via a user interface, in which case you could use a lookup table (one-to-many relationship) as you suggested. I don't know what database you're using, but here's some info on the enum type in MySQL: http://dev.mysql.com/doc/refman/5.6/en/enum.html.
If you use a lookup table, then AnObject should have a field called StateID that points to the desired row in the State table.
It sounds like DependsOn is a many-to-many relationship. For that you will need a join table, e.g.:
Table: Dependencies
Primary key (called a "composite key" because it's made up of more than one field):
AnObjectParentID
AnObjectChildID
I've assumed that the dependencies are needed for a parent-child relationship but if that's not the case you might want to name the table or fields differently.
You can add extra tables for enumeration values with a foreign key from AnObject to it. State will probably be best represented as a single field of type varchar not null. You can have the primary key for a table be a varchar field - they don't have to be int type.
This will constrain the values but allow you to use reasonable syntax to query the thing (i.e. WHERE state = 'Alive' (although in this case I think you're prematurely abstracting things - I'd keep it simple and just have a simple bool column IsDead).
DependsOn is a one-way attribute (you presumably can't have A depend on B and also B depend on A). The real issue here is how you're intending to query these items and how many of them there will be. If you want to pull out the whole chain of dependencies at once and the chain is long, you want to avoid doing hundreds of individual queries to do that. What is your use case?
I'm trying to design a MySQL database for a project I've started but I cannot figure out the best way to do it.
Its an OOP system that contains different types of objects all of which need to be stored in the database. But those objects also need to maintain parent child relationships with one another. Also I want the flexibility to easily add new data types once the system is in production.
As far as I can see I have three options, one that is pure relational, one which I think is entity attribute value (I don't properly understand EAV) and the last is a hybrid design that I've thought of myself, but I assume has already been thought of before and has a proper name.
The relational design would consist of two tables, one large table with columns that allowed it to store any type of object and a second table to maintain the parent child relationships of the rows in the first table.
The EAV design would have two tables, one being an EAV table with the three columns (Entity id, Attribute and Value), the second table would then relate the parent child relationships of these entities.
The hybrid design would have a table for each type of object, then a parent child relation table that would have to store the id of the parent, child and some sort of identifier of the tables that these id's come from.
I'm sure this problem has been tackled and solved hundreds of times before and I would appreciate any references so I can read about the solutions.
This is the only truly relational design:
CREATE TABLE Objects (
object_id INT AUTO_INCREMENT PRIMARY KEY,
parent_object_id INT,
-- also attribute columns common to all object types
FOREIGN KEY (parent_object_id) REFRENCES Objects (object_id)
);
CREATE TABLE RedObjects (
object_id INT PRIMARY KEY,
-- attribute columns for red objects
FOREIGN KEY (object_id) REFRENCES Objects (object_id)
);
CREATE TABLE BlueObjects (
object_id INT PRIMARY KEY,
-- attribute columns for blue objects
FOREIGN KEY (object_id) REFRENCES Objects (object_id)
);
CREATE TABLE YellowObjects (
object_id INT PRIMARY KEY,
-- attribute columns for yellow objects
FOREIGN KEY (object_id) REFRENCES Objects (object_id)
);
But MySQL does not support recursive queries, so if you need to do complex queries to fetch the whole tree for instance, you'll need to use another method to store the relationships. I suggest a Closure Table design:
CREATE TABLE Paths (
ancestor_id INT,
descendant_id INT,
length INT DEFAULT 0,
PRIMARY KEY (ancestor_id, descendant_id),
FOREIGN KEY (ancestor_id) REFRENCES Objects (object_id),
FOREIGN KEY (descendant_id) REFRENCES Objects (object_id)
-- this may need additional indexes to support different queries
);
I describe more about the Closure Table here:
My answer to What is the most efficient/elegant way to parse a flat table into a tree?
My presentation Models for Hierarchical Data with SQL and PHP
My book SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming.
Yes you can very well use the EAV design. It works for the application we created, although after about 3 years of refinement.
You can also use a generic table structure and use any particular table for a group of objects. Or just create one generic table for each object.
Which Table for which Object is part of a metadata repository.
If you use a val_int, val_string type of structure, you will have Null columns except where the value is stored. There are sparse matrix features of MS SQL which you might consider using. Disk size is somewhat cheap these days. So the only drawback you have vis-a-vis traditional structure is NxR rows (say R Attributes for the object) instead of N rows.
Other than that, few things to look out for are object instance GUIDs, dynamic sql generation...
The documentation for inaport states you can just map lookup fields and it will work out what types they are.
I am mapping from CRM 4 to CRM 2011 (using the CRM Connectors), however all my lookups fail with
A lookup value was mapped to account.{field name} but no target entity name was supplied and no default is available.
I have to fall back to adding a custom field, checking if their is a lookup id in the field, and then making a lookup value as per the documentation of guid::entityname using expressions which is painful.
Is this feature working for anyone else? Do i need to set up a child-parent relationship? I only ever add a map for the entity I'm working on.
Inaport will try to work out what the correct entity reference is and default it. For example, if the lookup is the foreign key in a child table, the entity reference will default to the parent.
There are some circumstances where a lookup may reference multiple entity types, and Inaport cannot infer the correct type. For example, and activity "regarding" lookup may reference 12 different entity types.
It could do a better job when a custom lookup is only referencing a single entity type, and a change request has been put into the system.
As you noted, when Inaport does not correctly infer the entity type you can force it by appending "::entityname" to the GUID you are mapping to the lookup field. This is discussed in more detail in the help.
HTH
Regards
David Evans