How can I define column to be unique when creating logical model? It's because I want to create relationship 1:N and both columns are not primary key. I tried to define surrogate keys when defining relationship and typed column names in field Name of source/target, but when creating relational model, I don't get what I want.
So basically I want define which columns from tables go into relationship and define unique constraint over column with multiplicity 1.
I found that I can set up Unique Constraints in the Relational Model in the Table Properties. There is an item in the list called "Unique Constraints" name the Constraint and then add the column. After that click the check box to generate the DDL for the constraint.
just use the UNIQUE constraint.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/clauses002.htm
BTW, why are you using a FK that does not reference the PK? You might need to do this, but you might also consider refining your conceptual model so that the reference can refer to the PK.
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.
What is the difference between defining a foreign key VS just creating an integer column named user_id?
// create_posts migrations
$table->integer('user_id')->unsigned();
// vs
$table->foreign('user_id')->references('id')->on('users');
Can they be used interchangeably? What purpose do each one serve? Which is considered a best practice, first or second definition?
Edit
The command $post->user() will work either ways, so what advantages does usage of a foreign key bring?
$table->integer('user_id')->unsigned();
// Above command is creating a column in database and it is required to have the required table structure
$table->foreign('user_id')->references('id')->on('users');
// Above command is creating foreign key index and making reference to id in users table.
As you can see from command explanations they can't be interchangeable, you need first command to have second command without first second command would complain.
Best practise is to use both of them together.
Few of advantages are listed below:
You can implement cascade update/delete.
Database level validation that only valid values of user_id is recorded ( to avoid some one entering 999999 which might be invalid or non existing user_id).
Above two are main advantages and you can express multiple scenarios how above two can be life saviour.
Let's say in post table by human error or bug in script makers user_id = 9999. What you think $post->user() will do?
Unless you can have a post without any reference to user you can see there could be multiple logical issue you may find if foreign keys are not used.
Think of foreign keys as enforcing relations and taking care of post if user is removed / deleted from db.
No, They can't be used interchangeably and each one has its usage. Use index when you want to define index on column, means database index, see here. But when you define a foreign key it set a index to that column (for searching, ...) and also make a relation between user_id and id column in user table, so if there is a user by id 10, then you can use user_id = 10 on another table. Also it has another benefits such as making sure your data are integrated. For example you can't delete user by id 10 if there is article that belongs to this user. For more information see this.
The first line, will only create a user_id column not something special,
while the other line will create a column as a foreign key which will be tightly coupled with id column of users table, this will create some limitations.
read about foreign key reference
For the best practices I always use:
$table->unsignedInteger('user_id');
$table->foreign('user_id')->references('id')->on('users');
Don't mix the definition of index with foreign key, they don't mean the same.
I am trying to implement an entity relation for a hospital oracle database system.
I am rather confused if I should seperate the table below or merge them into 1.
- Supply
ItemNo (PK) , Name, ItemDescription, QuantityInStock, BackOrderLevel, CostPerUnit
- PharmaceuticalSupply
DrugNo (PK) , Dosage, MethodOfAdmin
Basically in my ERD, I pointed PharmaceuticalSupply to Supply as a subset which inherits the attribute but also have additional attributes. Am I wrong in doing that?
Ultimately, this is a design decision that has no right or wrong answer, but keeping them separate can be helpful. For example, there are many types of supplies that are not pharmaceutical. If you merge the tables, you make it possible to enter data that has no real meaning. For example, you can't have a dosage of bandages. The separate table makes it clear that dosage only applies to pharmaceuticals.
Note that there are a few variations on how to manage the PKs and FKs in PharmaceuticalSupply. It could have both an ItemNo and a DrugNo, where ItemNo is a foreign key. In that case, either one could be the primary key, but if DrugNo is the primary key, then ItemNo probably needs to be a unique index. However, unless DrugNo is needed due to some custom format, it might work well to simply use ItemNo as both PK and FK and completely eliminate DrugNo. This results in a "specialization" as the relational database world likes to refer to it.
It depends on your population. It it's a subset, to reduce redundancy add a foreign key to Supply. That way you'll be able to build a join that list all data.
I would still introduce a DrugNo key for indexing. Can an item number appear more than once in the PharmaceuticalSupply table ? If your do then your definitely need the DrugNo key.
PharmaceuticalSupply
DrugNo (PK) , ItemNo (FK), Dosage, MethodOfAdmin
I am using Database First EF to generate model from the existing database. When I first generated the models, it ignores only one of the table, the entity was not added to EDMX, no model file is created for the table and no context is created for the entity.
When I tried to explicitly add the table to EDMX (when generating the model, selected the specific table first and then updated the model with all the other tables from the database), it complained with the following error.
Two entities with possibly different keys are mapped to the same row. Ensure these two mapping fragments map both ends of the AssociationSet to the corresponding columns.
This specific table has two columns which are primary keys of some other tables and both the columns are specified as Primary keys for the table.
Am I doing something wrong or should I handle this table differently since it has two columns defined as Primary Keys? Any suggestions greatly appreciated!
You are not doing anything wrong. Your table is junction table for many-to-many relation. You don't need that table in the model because EF (in contrast to database) can handle many-to-many relation directly without any intermediate. The table is actually mapped on behind of the many-to-many relation - you will see that in mapping details window.
Btw. you are not using code first. Code first = no EDMX.
I am analyzing an Oracle database design and I am perplexed at seeing both unique keys and primary keys on the same fields. These unique-primary key pairs are consistently created on all tables. I see no reason to do this.
If I have a primary key anyway, is there a good reason to create an additional unique key on the same field?
For a table resolving a many-to-many it would be common to have a two part key (as indicated by Quassnoi). It is also quite likely to need indexes supporting access through either parent.
If you have, for example, PERSON, ADDRESS and PERSON_ADDRESS tables, your PERSON_ADDRESS table may have the primary key of (PERSON_ID, ADDRESS_ID) and a supporting index. You would also have another index on (ADDRESS_ID,PERSON_ID), and you would likely make this a UNIQUE index (as it is a unique combination of fields).
It is also possible that your DBA has some particular way of generating tables that starts with a UNIQUE index on the primary key fields followed by the creation of the PRIMARY KEY constraint. That may show up in some GUI tools in the way you suggest.
No, there is no reason to have it also as unique; when you set a column as PK you are sure that:
No NULL will be accepted for that column on INSERT or UPDATE;
Values in the whole table for that column are always UNIQUE;
so just PK is enough. Since there is a UNIQUE index for the PK column, by definition, there is no need to add any other index on that column only because queries will use the PK index whenever only that column is affected.
I believe it's impossible (PK and unique constraint on the same column[s])...
You cannot designate the same column or combination of columns as both a primary key and a unique key.
(from here, section "Restrictions on Primary Key Constraints"). Isn't it?
Oracle won't let you create multiple UNIQUE and PRIMARY KEY constraints on the same field set in the same order and will fail with ORA-02261.
If you have composite keys, you can create PRIMARY KEY on the column set in one order (PRIMARY KEY (a, b)) and a unique constraint on another (UNIQUE (b, a)).
This will parse and execute, however a single index will be used to police both constraints so it makes no sense.
Could you please post the table scripts?
Just a little theoretical background here... When modeling your table, you identify a set of keys. These keys are logically equivalent, but for practical purposes you pick one of them and call it "primary" while the rest of them become "alternate".
(In DDL SQL, a primary key is called "PRIMARY KEY", while "alternate key" is called "UNIQUE constraint".)
So, in light of that, your question is equivalent to: "is there a good reason to have two identical keys", and the answer is: "no".
That being said, you may have overlapping keys (i.e. keys that share some fields but not all), but this is usually a sign of a bad design... and the answer is: "probably not".
OTOH, if by "unique key", you actually mean "unique index", then yes, you need both of them.
Index is not a logical constraint - it is there just to allow a logical constraint such as PRIMARY KEY to perform well (and for querying, but that's a different topic).