How to define two keys (PK and AK) in Microsoft Visio 2010? - primary-key

I'm using Microsoft Visio 2010 and I'm trying to draw my relational database model. For the Moment I have two tables: table1 with only one column "uid" (Primary key) and table2 with three columns "id" (Primary key), "uid" and "uorder". The last two columns combined form the alternate key. The relationship between these two tables is a foreign key from table2.uid to table1.uid.
How can I form the PK AND the alternate key in Visio? And how can I connect These two tables in Visio so they Show a 1 (table1) : n (table2) relationship?
Kind regards
Nadja

Related

Cannot use tables which have only primary key

I used a database first approach whereby I created the models from the database tables.
I have the following 3 tables:
CategoryTypeSex
ProductColor
ProductCategory
These are the only 3 tables that consist of only 2 fields (whereby both fields are primary keys and have a relation with other tables)
The screenshot above shows the diagram definition generated by mvc where the last 3 tables represent the tables mentioned above.
How can tables having only 2 fields which are both primary keys be accessed from the model?

MS Access Software Tracking Sheet

Im looking to see if i can create a database with MS Access.
I've got the jist of using Access but when i'm designing my tables im having some trouble finding something common to use between the tables.
So far I have.
Table Name: Software
SoftwareID - Auto-increment Primary Key
SoftwareName: Short Text
DateCreated: Date/Time
Table Name: User
UserID - Auto increment Primary Key
FNAME: Short text
LNAME: Short text
DateCreated: Date/Time
Table Name: Department
DepartmentID - Auto-increment Primary Key
DepartmentName: Short Text
Position: Short Text
DateCreated: Date/Time
anyone have any suggestions on what i can use to link the tables
To relate two entity sets in a many-to-many relationship, create a new table in which pairs of keys are recorded. For example:
DepartmentSoftware (SoftwareID PK/FK, DepartmentID PK/FK)
UserSoftware (SoftwareID PK/FK, UserID PK/FK)
In both tables, we make both columns part of the primary key since it's the combination of the two values that are unique (this makes it a many-to-many relationship, if only one column was included in the primary key it would be a one-to-many relationship). We also add foreign key constraints to ensure that nonexisting software, departments and users don't get inserted or left behind.

SQL M:1 relationship

I have to make a M:1 relationship using SQL Server but I've been wondering if the column representing the "many" side should be foreign key and the column representing "one" side should be primary key.
The purpose is retrieving information from the table with the column representing "one" side using the table with the column representing "many" side.
Do you thing this idea is reasonable and would work successfully?
I've been wondering if the column representing the "many" side should
be foreign key and the column representing "one" side should be
primary key.
The column representing the many side is indeed a primary key of a table, and the column representing the one side is also a primary key of another table. But there is a new column in one of them, is a foreign key that connect each others(this column is the column that makes the relation many to one, and that is the column you should care of).
So, you have to make them into two tables. Consider the following Many to one example:
Countries and cities relation: One Country has many cities.
This would be represented with two tables:
Countries:
CountryID primary key,
Name.
Cities:
CityID primary key1,
CountryId foreign key references Countries(ID),
Name.
And that is how you should create a many to one relation as follows:
The columns CountryID and CityID are primary keys in the two tables.
The column CountryID which represents the one side is a foreign key in the many side(cities table). That is the column that you should
1:You should have a composite key instead of a primary table in the Cities unless you want a city to be in more than one Country at the same time.

Question About seting MS Access Relationship type

I have two tables A,B like
A(A_pk_id,A_name), B(A_pk_id,B_pk_id,B_Name);
Here A_pk_id is primary key of table A, And table B has composite primary key comprising of two fields A_pk_id(Table's primary key),B_pk_id,
Now whenever i tried to define relationship between these two tables [on A_pk_id] MS Access 2007 set their relationship type 1 to 1, but i want it to be 1 to many, cardinality of table must be set to 1.
Can any body guide how i could accomplish my goal.
Regards
Ahsan
If you're getting a 1:1 relationship, it means you're joining two fields that both have a unique index on them (regardless of whether both are PK or not). The many side needs to have a non-unique index.

Designing 1:1 and 1:m relationships in SQL Server

In SQL Server 2008, how does one design a 1:1 and 1:m relationship?
Any relationship requires that the "parent" table (the one side) have a Primary (or unique) Key (PK), that uniquely identifies each row, and the "child" table (the other side) have a Foreign Key column or columns, that must be populated with values that are the same as some existing value[s] of the Primary Key in the parent table. If you want a one to many (1-M) relationship then the Foreign Key should be an ordinary attribute (column or columns) in the child table that can repeat (there can be many rows with the same value)
If you want a one to one (1-1) relationship then the Foreign key should itself be a Primary Key or unique index in the child table that guarantees that there may be at most one row in the child table with that value.
A 1-1 relationship effectively partitions the attributes (columns) in a table into two tables. This is called vertical segmentation. This is often done for sub-classing the table entities, or, for another reason, if the usage patterns on the columns in the table indicate that a few of the columns need to be accessed significantly more often than the rest of the columns. (Say one or two columns will be accessed 1000s of times per second and the other 40 columns will be accessed only once a month). Partitioning the table in this way in effect will optimize the storage pattern for those two different queries.
Sub-Classing. The above actually creates a 1 to zero or one relationship, which is used for what is called a sub-class or subtype relationship. This occurs when you have two different entities that share a great number of attributes, but one of the entities has additional attributes that the other does not need. A good example might be Employees, and SalariedEmployees. The Employee table would have all the attributes that all employees share, and the SalariedEmployee table would exist in a (1-0/1) relationship with Employees, with the additional attributes (Salary, AnnualVacation, etc.) that only Salaried employees need.
If you really want a 1-1 relationship, then you have to add another mechanism to guarantee that the child table will always have one record for each record/row in the parent table. Generally the only way to do this is by enforcing this in the code used to insert data (either in a trigger, stored procedure or code outside the database). This is because if you added referential integrity constraints on two tables that require that rows always be in both, it would not be possible to add a row to either one without violating one of the constraints, and you can't add a row to both tables at the same time.
One-to-One Relationship
Create Table ParentTable
(
PrimaryKeyCol ... not null Primary Key
, ...
)
Create Table ChildTable
(
, ForeignKeyCol ... [not] null [Primary Key, Unique]
, ...
, Constraint FK_ChildTable_ParentTable
Foreign Key ( ForeignKeyCol )
References ParentTable( PrimaryKeyCol )
)
In this case, I can never have more than one row in the ChildTable for a given ParentTable primary key value. Note that even in a One-to-One relationship, one of the tables is the "parent" table. What differentiates a One-to-One relationship from a One-to-Many relationship purely in terms of implementation is whether the ChildTable's foreign key value has a Unique or Primary Key constraint.
One-to-Many Relationship
Create Table ParentTable
(
PrimaryKeyCol ... not null Primary Key
, ...
)
Create Table ChildTable
(
, ForeignKeyCol ... [not] null
, ...
, Constraint FK_ChildTable_ParentTable
Foreign Key ( PrimaryKeyCol )
References ParentTable( PrimaryKeyCol )
)
In this scenario, I can have multiple rows in the ChildTable for a given ParentTable primary key value.
A 1:1 relationship exists where table A and table B only exist once in regards to each other.
Example: A student has 1 master student record. The student would be table A and the record in table B. Table B would contain a foreign key to the student record in table A (and possibly vice-versa)
A 1:m relationship exists where table A can be referenced or linked to by many entries in table B.
Example: A student can take several books out from the library. The student again would be table A and the book could be the entry in table B. The entry in table B would contain a foreign key to who checked the book out, and many books could reference the same student.