I have question about inheritance representation in ERD-diagram.
The following example:
I have plane, and I have also two types of planes
1-PersonsPlane
2-CargoPlane
I am confused about which relationship to use ( 1-to-1 OR 1-to-Many). My DB teacher told me that I should use a 1-to-1 relationship, But I have found on the internet many examples use (1-to-Many) relationship instead of (1-to-1).
Check these images:
One-to-One relationship
One-to-Many relationship
Which one is correct??
inheritance relationship in ERD should be represented as One-To-One relationship or One or Zero-to-One relationship depending on the case.
1) 0..1-1 : If there could be an entity of plane since plane can exist without having child entity like cargo or personal but cargo and personal cannot exist without having a parent plane entity.
2) 1-1: If each entity cannot exist by it self. The PK in plane is the foreign key and primary key in cargo and personal child tables.
I don't think that in any case it is a one-to-many and I will give you an example: a db record of plane pk=1. Two db record of personal plane with foreign key=1 referencing one record in parent plane table. This means that there are two children entities with same key which is wrong. There must be only one referenced record in the child table thus 0..1-1 or 1-1 relationship.
ER modeling (or, more precisely, EER modeling) has a way to represent inheritance in the diagram. It goes by the name "generalization/specialization". You can find a number of good articles on the web by searching on this.
The diagramming technique doesn't tell you how to design relational tables that reflect this inheritance situation. That's really more a matter of database design than ER diagramming. If you look up Martin Fowler's treatment of "class table inheritance" or "single table inheritance", you'll get a good presentation of some design patterns.
There are tags with those names here in SO, and the info under those tags is helpful, as well as the questions that have been tagged with them.
Related
This is a portion of a Gaming Company Chen diagram that I need to convert to a database. How do I know which entity will get the attributes LastPlayed and CreatedOn? I feel like I could make a case for either entity. It could be the LastPlayed and Created on of the Account or the Character. Is there a rule for this? TIA
The attributes you show belong to the relationship, and not either of the entities. In this case, practically speaking implementation would make them part of the (N) side of the relationship, that is, the Character entity.
The distinction between entity-attributes and relation-attributes only really matters for many-to-many relations that have to be implemented by converting the relation into its own table.
Before starting to develop anything, I made a draft of a ER diagram using Chen's notation, when developing the web page I had to change some stuff on the database, and at the end I got this ER diagram:
Between "booking" and "staff" tables I have a relational table "assign".
But between "booking" and "parts" I have this "cost" which I believe its the relational one, but I dont know how to represent it on Chen's notation diagram. Can someone give me a help? :)
Thanks.
In this physical ERD diagram, which shows how primary and foreign keys are used to implement the relationships.
From the conceptual point of view:
assign implements a many-to-many relation between staff and booking;
cost implements a many-to-many relation between booking and part that provides additional information about the combination between booking and parts.
In Chen's notation:
assign would be represented with a simple losange for relationship and a cardinality M, N.
cost would also be representad with a many-to-many relationship losange. But in addition, you'd show the relationship's attributes (e.g. quantity, cost, description) as additional ellipses connected to the relationship
You could also consider to use associative entities instead of realationships, especially for cost. It has the advantage of suggesting that there's a table behind. But it's not required in your model, unless cost could have relationships with other tables (which would be easy since there's a cost_id)
I have the following issue with designing entity schemas.
Let's say that I've created a schema full of many-to-many relations, because it seemed like a reasonable choice at first, but during implementation those relations are not needed.
For example, theoretically each county can have many lakes and each lake can be located in many counties. But my database has no lakes crossing borders of the counties. Is it still reasonable to use many-to-many relations? It'll basically create a junction table that serves no need, because I can represent it with one-to-many relationships.
I have a geographical database that I intitially thought would contain a lot of many-to-many relations, but in practice such relations are needed only in a few tables.
First of all: It's related to your Software Functional Requirements.
Your System Analysts should decide on that. And System Analysts should follow System Owners, End Users, and other Stakeholders within the organization.
If you write a project for an organization or company, you should ask them.
Secondly: In Database Design, if you have even few countries that can have common lake, you should use many-to-many relationship. The reason is Extendability of your project. I don't think many-to-many has a lot of difficulties in comparison with one-to-many.
Thirdly: If you have a few (seldom) countries that can have common lake, I think you can use this data modeling technique:
You can use combination of one-to-many and many-to-many.
Add primary key of Country as F.K to Lake. (for one-to-many relationship)
Add new table like Country_Lakes with F.Ks from Country and Lake (to many-to-many relationship)
How to detect the Lake type (common or not): If the F.K of Country in Lake is NULL, this Lake is common, you can get all Countries from Country_Lakes.
In this design, you have a little Nullification, but it happens seldom.
If you might be using it, keep it. Creating many-to-many relationships afterwards is far more complicated.
If you won't ever use it, remove it.
I have to create an ER diagram based on a relational schema.
There is a table of players, and a table of zones. A player can 'live' in many zones, and each zone is owned by one or more players.
I've come up with this simple ER diagram but I'm not sure having relationships going each way is allowed?
Cheers
Yes, that is a perfectly good Entity Relation Diagram. (I am not responding as to whether it makes sense or not: you still need to resolve the Relations and Cardinality.)
Using the correct terms helps people understand exactly what you are discussing, and which level you are discussing. Loose talk results in much more volume in the discussion, and time wasted in clarifying what you meant by which term. Not good for productive technical endeavours.
At this early stage, it is normal to model Entities and Relations (not Attributes), that's why it is called an ER diagram; we are nowhere near modelling the data. The Relations are relevant, and that's why you are detailing and evaluating their nature in the diamonds and Cardinality. The goal is to clarify the true Entities, and their Relations to each other. Many-to-many relations remain as relations. The ERD is purely Logical, there is no Physical.
Once you have some confidence with that, that you have gotten the Entities and Relations right, you move onto a Data Model (which includes Attributes). Still at a Logical level, the n::n relations remain as relations.
As you progress, you may show further detail, such as Domain for each Attribute. That's the DataType, but at the Logical level, just as the terms are Entity = Table and Attribute = Column, Domain = DataType.
.
When you get to the Physical level, the Data Model has Tables; Columns; DataTypes.
And n::n Relations are manifested as the Associative Tables.
.
The idea is, as long as you are working through the prescribed steps, at (1), the content in the diamonds will determine (expose) if they need to be stored, and the diamond is thus promoted to an Entity; otherwise it remains a Relation.
There is a junction table called lives-in in the relational schema I've been given. However, I thought when mapping a relational schema [back] to an ER diagram a junction table becomes a relationship?
The Relational term is Associative table.
Yes. If it is a pure n::n Table (containing nothing but the two FKs to the PKs of the parent Tables), at the ERD level, which is Logical only, it is a Relation.
If it has Columns other than the two FKs, it is an Entity.
Since there's a many-to-many relationship between [Players] and [Zones] you have to add a junction table (called for ex. [PlayersZones]). The notation itself is correct (Chen notation), though I prefer the Crow's Foot Notation.
I am not able to see your images (blocked!) so I'll just try to describe the "correct" design. If a player living in a zone doesn't necessarily mean they own it, you should have four tables:
PLAYER (playerid, <other fields>)
ZONE (zoneid, <other fields>
PLAYER_ZONE(playerid, lives_in_zoneid)
ZONE_OWNER (zoneid, owner_playerid)
Otherwise three tables would suffice.
There are couples of questions around asking for difference / explanation on identifying and non-identifying relationship in relationship database.
My question is, can you think of a simpler term for these jargons? I understand that technical terms have to be specific and unambiguous though. But having an 'alternative name' might help students relate more easily to the concept behind.
We actually want to use a more layman term in our own database modeling tool, so that first-time users without much computer science background could learn faster.
cheers!
I often see child table or dependent table used as a lay term. You could use either of those terms for a table with an identifying relationship
Then say a referencing table is a table with a non-identifying relationship.
For example, PhoneNumbers is a child of Users, because a phone number has an identifying relationship with its user (i.e. the primary key of PhoneNumbers includes a foreign key to the primary key of Users).
Whereas the Users table has a state column that is a foreign key to the States table, making it a non-identifying relationship. So you could say Users references States, but is not a child of it per se.
I think belongs to would be a good name for the identifying relationship.
A "weak entity type" does not have its own key, just a "partial key", so each entity instance of this weak entity type has to belong to some other entity instance so it can be identified, and this is an "identifying relationship". For example, a landlord could have a database with apartments and rooms. A room can be called kitchen or bathroom, and while that name is unique within an apartment, there will be many rooms in the database with the name kitchen, so it is just a partial key. To uniquely identify a room in the database, you need to say that it is the kitchen in this particular apartment. In other words, the rooms belong to apartments.
I'm going to recommend the term "weak entity" from ER modeling.
Some modelers conceptualize the subject matter as being made up of entities and relationships among entities. This gives rise to Entity-Relationship Modeling (ER Modeling). An attribute can be tied to an entity or a relationship, and values stored in the database are instances of attributes.
If you do ER modeling, there is a kind of entity called a "weak entity". Part of the identity of a weak entity is the identity of a stronger entity, to which the weak one belongs.
An example might be an order in an order processing system. Orders are made up of line items, and each line item contains a product-id, a unit-price, and a quantity. But line items don't have an identifying number across all orders. Instead, a line item is identified by {item number, order number}. In other words, a line item can't exist unless it's part of exactly one order. Item number 1 is the first item in whatever order it belongs to, but you need both numbers to identify an item.
It's easy to turn an ER model into a relational model. It's also easy for people who are experts in the data but know nothing about databases to get used to an ER model of the data they understand.
There are other modelers who argue vehemently against the need for ER modeling. I'm not one of them.
Nothing, absolutely nothing in the kind of modeling where one encounters things such as "relationships" (ER, I presume) is "technical", "precise" or "unambiguous". Nor can it be.
A) ER modeling is always and by necessity informal, because it can never be sufficient to capture/express the entire definition of a database.
B) There are so many different ER dialects out there that it is just impossible for all of them to use exactly the same terms with exactly the same meaning. Recently, I even discovered that some UK university that teaches ER modeling, uses the term "entity subtype" for the very same thing that I always used to name "entity supertype", and vice-versa !
One could use connection.
You have Connection between two tables, where the IDs are the same.
That type of thing.
how about
Association
Link
Correlation