1
General Board / Re: Elements and Associations are moving on their own...
« on: October 10, 2024, 01:57:57 am »
Use lock diagram menu (right click on the diagram)
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Does UML support relationships between (different) relationships?Not explicitly, but several of the relationships (eg. Dependency) have ends defined by types that include a number of relationships.
That doesn't necessarily mean that it's expected. LiteralNull is also a specialization of Element, so you could also have a dependency on a particular literal null. I don't think that's a reasonable interpretation of the intention of the specification.Surprisingly I can draw a trace relationship from a relationship to itself in SparxEA. Is this intended?I don't see a constraint on the specification that disallows it. You could argue that it's not expected by the authors of the spec, but I don't know how end users are using it. If you don't think it makes sense, don't use it.
In the current Office MDG it's impossible to set primary/Foreign key constraint on import of classifiers of type <<table>>. This is a pity because the MDG allows us to reverse engineer any database using the DBMS object metadata. My suggestion is:
3. Add capability to assign primary key constraint to any column to the classifier import profile (keep in mind composite keys)
4. Add capability to assign primary and foreign key constraint to any column to the connector detail profile (keep in mind composite foreign keys and primary key that include a FK)
You can't use recursive queries in EA searches, or Repository.SQLQuery
They need the query to start with Select
You can cheat EA with internal query syntax, like below:Code: [Select]SELECT q.* FROM (
<any_query_not_starting_with_select_keyword>
) q;
It works on PostgreSQL repository, and I'm pretty sure, this syntax (or similar) is possible in many other SQL engines.
I know I tried this a few years ago and couldn't get it to work for searches in SQL Server. I never really bothered anymore once the #Branch# macro became available.
Geert
WITH RECURSIVE pkgbranch (eaguid, pkgid, pkgname, parentid, lvl) AS
(SELECT p.ea_guid, Package_ID, p.Name, p.Parent_ID, 1
FROM t_package p
WHERE p.ea_guid = '{xxxx}'
UNION ALL
SELECT p.ea_guid, p.Package_ID, p.Name, p.Parent_ID, pb.lvl+1
FROM t_package p
JOIN pkgbranch pb ON pb.pkgid = p.Parent_ID)
SELECT * FROM pkgbranch;
CASE WHEN t_attribute.IsOrdered = 1 THEN 'Y' ELSE '' END,--PK
CASE WHEN t_attribute.IsCollection= 1 THEN 'Y' ELSE '' END,--FK
CASE WHEN t_attribute.AllowDuplicates = 1 THEN 'Y' ELSE '' END,-- NN; Weird but correct
CASE WHEN t_attribute.AllowDuplicates = 1 or t_attribute.IsStatic = 1 THEN 'Y' ELSE '' END,--Unique NEED TO ADD OTHER UNIQUE FROM CONSTRAINTS
It seems to me that you are describing a dependency between database objects. Something that would be implemented via a trigger (eg if field x in table 1 is equal to a, then field y in table 2 must be equal to b).Hi Richard, are you referring to what Geert is discussing or my original thesis?
Dependencies are used to model this kind of constraint (and also to model the source objects queried by views).
In our case, they are conceptually associations and work fine between all other types of items. It's just when we try to create the same semantics between DB Tables, EA gets in the way...
Paolo