I am having trouble understanding how to create recursive one to many relationships in a logical model built by Oracle data modeller.
The relational relationship should be similar to this i.e Manager ID is a FK for the same table
I have my logical model set up as so:
However, when I engineer to relational this is my result.
This behaves fine if I am creating a relationship for two different tables, Manager and Employee. PK on source table appears as FK target table.
How can I set up my logical model to create one FK called managerID with a one-to-many relationship on the same table?
Thanks.
i faced it initially.I think you have done the steps correctly, its just the notation is not showing the linkage as i see the linkage in the diagram but the attribute is not visible in the diagram.Try switching from Barker notation.
go to View>>Logical Diagram Notation >>Information Engineering Notation
let me know if this resolved your mystery :)
Related
I have two fact tables: FactSales & FactInvoices. Both have an foreign key relationship with DimDate.Datekey. In VS, the SSAS DSV displays these relationships (the lines are drawn between the tables).
In the DSV I decided to to create a named query that limits the dimdate to 2021. After doing this, I still see the relationships between the two fact tables and dimdate (which is now a named query).
At the DB-level, I created a 3rd fact table called FactExpenses. FactExpenses also has an FK relationship with DimDate.Datekey. The problem is that my dsv (in SSAS) does not recognize this relationship (ie. It doesn't draw the line between both tables).
Two questions: why doesn't VS display the relationship between my 3rd fact table with the named query but it does with the other two fact tables? I understand that the relationship isn't with the named query, but the relationship should disappear in all the fact tables.
When I want to limit the amount of data displayed in dimdate, should I use a named query?
The relationships in the DSV are separate to the foreign keys on the base tables, but they get added automatically based on the database schema when you add tables to the DSV. My guess would be when you added the initial dim and fact tables to the DSV in Visual Studio it automatically added the relationships based on the foreign keys that exist on the base tables, but this may not occur automatically for named queries. You can manually add the relationship yourself for the third table to get the same result.
I think a named query is a reasonable approach for the filtering you want to do. An alternative would be to create a view in the source database if you need to do more intense or complex filtering.
I have a Laravel 8 application and am wondering how to solve the problem of how to solve a typical polymorphic issue. I have an Employee model. That Employee can be an ExecutiveEmployee or EntryLevelEmployee. There will be methods an ExecutiveEmployee has that an EntryLevelEmployee doesn't have and the inverse is also true.
Using Laravel 8, is it right to create a base Employee model (without a corresponding table?) and then create two models named ExecutiveEmployee and EntryLevelEmployee that inherit from Employee? This would also imply that both employee types will have two different database tables, even though there will be a lot of overlapping data.
Does it make sense to just have one Employee model and create a migration that has the employee type listed in the model? I am assuming that it's ok if an EntryLevelEmployee has some database attributes which are relevant to it that may or may not be relevant to an ExecutiveEmployee type here, or is that an incorrect assumption?
What's the correct way to model this in Laravel 8? I prefer to keep everything in one table because of how similar the models are. I do have to keep in mind that there will be data that one has that the other doesn't. There will be different accessor methods as well.
Is it possible to have everything in one employees table while utilizing multiple models? Meaning, if I create two models named ExecutiveEmployee and EntryLevelEmployee they would both query the underlying table employees?
UPDATE 1
The more I research, the more I think polymorphism is the incorrect approach here and what I might need is Single-Table Inheritance. This package seems to bring the capability to Eloquent. Would there be a good reason to not use this?
I would use polymorphic relationships in this case, because you are more flexible and have less coupling.
Using the Single Table Inheritance (STI), you can add type specific columns in the employees table and make them nullable. But think about adding/removing types in the future.
executive_employees
id - integer
executive_specific - string
entry_level_employees
id - integer
entry_level_specific - string
employees
id - integer
name - string
email - string
employable_id - integer
employable_type - string
As for the STI the same would be
employees
id - integer
name - string
email - string
type - string
executive_specific - nullable string
entry_level_specific - nullable string
So STI would be suitable when you don't have type specific columns. But you want to add specific behavior in your code. For example a User type (Admin, Author).
Even so, it's a matter of preferences.
It really depends on the state and behavior of your employee object.
Below are few points I will consider to make a decision
If your objects' states/properties are different then definitely you will create different models as your data will be stored in different tables.
If most states/properties are same and some are different, you can
consider storing all in one table/model and for the difference in
behavior create separate table like Ron Van Der Heijden has
suggested and you can consider query scope with that to make
transaction with database.
And another view will be
How many JOINs you will create if you will create different tables,
will that impact the performance and other stuffs, will it make your
code complex?
Can you make simpler relations and handle stuffs independently?
When you are making an API, will your
code make the api overworking? or you need to create too many request
for any operation?
These stuffs will decide how you will make a decision.
Update 1:
Another point I would like to add about the package you are thinking to use, consider using a parent key in table and you can define relationships in a single model.I do not think you need to use a package, you can define it yourself, I guess.
I don't understand why you don't create a simple one-to-many relation. Based on the information you provided, the polymorphic relation looks unnecessary. I think the right way is to create employee_roles table and relations. Then you can give different permissions to different employee types. There are several ways to do that. You can create a middleware to create route restrictions. You can check the role before executing a function in the controller, and run only if the employee has permission. You can use if-else in blade not to render the parts that can't be used by auth user etc.
If you have different “types” of employees, and each employee type should have different logic then yeah, that sounds like a polymorphic relationship.
I'm developing a ADF Fusion Web Application and have some problems with EntityAssociations and ViewLinks.
I have a database table Project with id, name etc. Also I have a table Technology which only contains a id and the name of the technology, for example "ADF".
The relationship between theese two entities is many-to-many. Means one project can have multiple technologies assigned and inverse a technology can be assigned to multiple projects.
This relationship is described trough a join table named Project_Technology. Columns of this table are Project_FK, Technology_FK and Effort. Project_FK and Technology_FK are a composite primary key, Effort is an additional attribute.
Can someone explain me how to map EntityObject and ViewObjects that I can access the Effort, too? "Regular" many-to-many associations aren't that hard to implement but I am really struggling with the additional attribute.
Any help is appreciated. Thanks in advance!
Edit:
I could solve my issues. See answer below for details.
I got it working.
The Problem was the composite primary key on my join tables. It seems like ADF doesn't like them. I put a extra column ID on the join tables and now I can insert values by using the CreateInsert Data Controls.
I'm using CodeIgniter and I'm starting to work with gas orm.
One of my m-n-relationship-tables using a composite key has also some additional attributes to the releation.
For Example:
Table teams, Table employees, and a m-n table which binds them together + adding the attribute role
Is it possible to get the attribute using GAS ORM?
Yes, it is possible.
Simply create a new relationship in one of the two tables you are going to link with the pivot table that refers to the pivot table itself as a has_many relation. (But dont do the linking stuff in the model file, eg:
ORM::has_many('\\Model\\User\\Role')
instead of
ORM::has_many('\\Model\\User\\Role => \\Model\\Role')
See http://ellislab.com/forums/viewreply/1050559/ for exact the same question.
So, this is a bit complicated: I have two tables, say cats and dogs.
They are in a many-to-many relationship (could be called friendships or whatever), so that Doctrine automatically creates a table cats_dogs for me with the appropriate fields. (that is rowid, cat_id, dog_id per default.)
Now, imagine I have a third table, award, where I want to award one of these friendships. Here I therefore need a field that references one row in cats_dogs. However, since this table does not really exist between my models, (Doctrine handles it for me) what would be the most elegant solution for this?
In the end, I want in my award model two fields, a cat and a dog, who need to be in a friendship.
I am using the annotation driver.
What stops you from manually creating the m:n table instead of having doctrine do it for you?
The Doctrine aims is to map objects from an E/R schema and to make easier the access to object connections. Therefore I believe that the table cats_dogs automatically provided by Doctrine is necessary as it is. It is concise and hits its purposes, i.e. it provides a list of all dogs of a cat or, vice versa, all the cats of a dog.
Thus, I can conclude that it is preferable to create a third entity (besides Cat and Dog) named Award which provides a one-to-one relationship with Cat and another one-to-one relationship with Dog. Making it consistent with the cats_dogs table is only up to you, and is not a Doctrine task by default. E.g., you can use some cascade persist option.
I believe that this is the most effective solution with Doctrine.
As a final remark, consider that each table should map a specific relationship between one or more entities, and in fact the table cats_dogs represents the friendship relationships, while the table Award will represent the awarded relationship relationship between two friends.