I am using DIA v0.97.1 to draw an entity relationship diagram with UML sheet for my database model. However, I tried and failed to find a switch allowing me to add cardinality notations (e.g. 1...n) on those relationship lines. Is there such a feature in Dia? Or I have to install some plug-ins? Thanks.
the cardinality of relationships is set inside the relationship box. double click it to find its properties. first three properties are name, left cardinality and right cardinality :) this way they remain locked to the relationship box and not the line. which actually makes more sense.
also, make sure you're using the model sheet "er", and not "uml", since the "uml"-sheet lacks the relationship box. "er" only has 5 thingies, but they're really all one needs for er diagrams.
Related
I am trying as an exercise for an exam to transfer a database from the ER model to a relational database.
However, I am very unsure whether my solution makes sense. In particular, the two relationships between location and has makes great problems. I thought I could add one ZipCode as a regular primary key into the table has and a second ZipCode as foreign key. I would be very grateful if someone could help me with this.
My Solution so far:
If you are following Chen ER design with this Chen ER diagram then you need a table for every entity type box and every relationship (association) type diamond and a FK (foreign key) for every participation/role line for a relationship type.
(It is a bad idea to call lines/FKs "relationships" or "associations" in a Chen context because diamonds/tables represent relationship types and lines/FKs represent participations.)
So your Ship tourID would be dropped in favour of relationship/table takes with lines/FKs to Ship & Tour. And you would have two FKs in the has table to Location. It doesn't matter that you need different column names in the relationship table than in the participant table. A FK just says the values in some table & column list appear in some other table & column list. The diagram says the names are start & target; use them.
Don't use a flaccid uninformative name like has. If you picked a better name and/or explained when a triplet of entities satisfied the has relationship then we could know what reasonable designs would be. Eg you may not be using cardinalities correctly. The Chen way is, a number or range tells for some instance of the entity type how many relationship instances it can participate in. Another way is, a number or range tells you for a some combination of entity instances of the other participating entity types how many instances of the line's entity type can participate with it. If the latter has a zero that means a relationship instance can have a NULL. But that can't arise in a Chen design; participating entity instance combinations identify relationship instances and form PKs (primary keys).
However, a Chen design can't express all relational designs. And we can represent the same data as a Chen ER schema by rearranging tables. Eg dropping binary relationship tables that are not many:many and putting FKs (sometimes nullable) into entity tables instead, just as you did with takes, Ship & Tour. Some methods have non-Chen diagrams expressing such designs directly. Others allow it in the move from Chen diagram to schema. You have to ask your teachers whether they care just what variations from the Chen style of ER diagrams and corresponding schemas you are permitted to make.
(It is this dropping in non-Chen methods of explicit 1:many relationships/associations and their representation by FKs that leads to FKs being incorrectly (but commonly) called "relationships" or "associations".)
I am new in DB design,need advice to design correct number of tables and columns from excel sheet with this columns:
If multiple locations available or Foil is Y for a cardname then you see multiple rows for that cardname.
Identify the entities that your data model needs to represent.
An entity is briefly defined as: a person, place, thing, concept or event that can be uniquely identified, is important to the business, and we can store information about.
Also, identify the relationships between the entities.
The usual approach is consultation with the data owner/system owner; asking appropriate questions, throwing some ideas down in an entity relationship model, and asking further questions reviewing what is right about the model, and what isn't... altering and refining the model.
From the very brief description in the question, we would likely propose, as a starting point, some proposed entities: card and location.
Identify candidate keys:
What uniquely identifies a card?
What uniquely identifies a location?
Identify the cardinality of relationships (how many on each side of the relationship?
Can a location be related to more than one card?
Can a card have more than one location?
Must a card be related to a location (can we have a card that doesn't have a location?
etc.
Then, then assign the non-key attributes to the appropriate entities. Aim for third normal form.
"Each attribute is dependent on the key, the whole key, and nothing but the key. So help me Codd."
I'm trying to represent a simple classification scheme via a relational database. Or more specifically I'm trying to figure out if it's a good idea or not.
When I look at an image such as this http://www.talkstandards.com/wp-content/uploads/2009/10/taxonomy-of-standards.jpg, that I just picked off google, I see a bunch of one-to-many associations. that this happens to be amphibians is purely coincidental as I'm not a biologist.
I'm pretty new at databases and just wondering if there is a good way of dealing with a hierarchical taxonomy like schema
Just an example : same table case
Make a column to forein key parent and a column for the level
At top level node is 1 and parent is null;
I just started to take data base managements and I want to know something. Can I make a connection between 2 relations? I mean there wont be any entities or atributes between them. Is it correct If I do this?
In-order to make a connection between two relations (tables) each table must have one or more columns which can somehow relate to the other table.
From the following example we are able to make a relation based on the knowledge we know about animals, even though the two tables have no attributes or entities between them that are the same.
I am currently developing a database via MS Access 2003 and got stuck at a circular reference problem. Basically, it comes down to the following relationship triangle (it is a simplified form of my relationship table):
Positions
oo oo
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
oo oo
Employees oo -------------------- oo Software,
where Positions, Employees and Software are the tables, and "oo-------...-------oo" displays the many-to-many relationships between them.
In short, all of the employees in a company are assigned to specific positions (some of them are assigned to more than one), and have permissions to use specific piece(s) of software based on their position(s). However, there are exceptions, and some of the employees are granted to use a few number of other software packages, in addition to what they are allowed to according to their position(s).
The question is, is it OK to allow a circular relationship in this kind of database? Are there any workarounds that do not require denormalization?
Thanks in advance,
VS.
Your diagram is elliptical in the sense that you've left out the N:N join tables between all your entities. Those make a HUGE difference in regard to the side effects of circular relationships. Direct 1:N relationships with CASCADE DELETE on can cause real problems, and potential deadlocks. But with the N:N tables in between, you shouldn't have that problem, as CASCADE DELETE would run only "downhill" from the 1 table to the N, and not back up the chain from the N:N table to the other parent table.
It seems to me that this is a common problem, isomorphic with the address problem, i.e., a person can have a personal address and inherit an address from the employer, and #Saif Khan's solution of eliminating the software inheritance from the position is a form of denormalization, in that you've collapsed two complex entity relationships into a single one. I never know how to model this, not because of potential circular relationships, but because of the performance issues (and non-editibility) that come from assembling a single result set of all software/addresses, which requires a UNION. I would be tempted to use a trigger to duplicate the software inherited from the position with a record linking the person to the software.
Prior to A2010, this was not possible at the engine level in Access/Jet/ACE, but A2010 added table-level data macros which can be used to implement the equivalent of triggers. This could be a case where that new feature could allow you to implement this structure with triggers.
But I'm not sure I'm comfortable with duplicating data, even though triggers would allow you to keep the duplicated data in synch at the engine level.
You could avoid it by generating new position for each of the exceptions. A boolean flag could then be added to the position to differentiate between real and exception generating positions, if required.
You need to properly normalize the DB. IMHO - I'd not use a relationship in the positions table. Here is what I'd do
Tables
Employee
Software
EmployeeSoftware
Position
The "POSITIONS" table in your case, i assume, is your roles. Note the DB should be used as storage and very minimal business logic should be placed there. That being said, ...let me continue
There will be a relationship between Employee and EmployeeSoftware (empid present as foreign key in EmployeeSoftware. The same for Software and EmployeeSoftware (softid present as foreign key in the EmployeeSoftware.
The application first checks if a person is in a proper position (POSITIONS) table before inserting a record. For an additional DB check you can add a check contraint on the EmployeeSoftware to check the POSITIONS DB before...there then need to be a Relationship between Software and Positions.
I think this database design is getting too complicated because of the way of handling the exception,
"some of the employees are granted to
use a few number of other software
packages, in addition to what they are
allowed to according to their
position(s).
Don't try to directly link an Employee to software.
I would just create another position because the main purpose of position in this case is to determine software access. Even if one person has a unique list of software, they will get replaced in the future and that person can just be assigned the same position(s).
Querying will be easier. As David-W-Fenton pointed out, you're going to have to use a lot of unions to find out who can use what software or vice versa.