I need to create an ER diagram and a relational model for a hospital. I have kept it simple to 3 entities. Please can someone have a look and tell me if I have normalised this correctly?
I am not sure it there should be a : relationship between the trust and patients? Does a person assume that the first entity is a single unit, in this case a hospital has x relationships to....
Diagram 2:
ER Diagram & Relational Schema
Your normalization isn't correct. First of all, you don't list functional dependencies. Without that, any attempt to normalize is just guesswork.
Now, I can make a reasonable guess, but even with that you have some problems. The Hires and Cares for relations aren't reflected in your 1NF/2NF/3NF tables. In your 2NF, you introduce a Shift relation that was presumably derived from Doctor in 1NF, but Patient_ID wasn't present in the latter, unless that's actually what the Shift column was for, but renaming fields isn't part of normalization. Also, what happened to Hospital in 2NF? It reappears in 3NF but with a Location attribute that was derived from where? Also, you're not indicating a primary key for Shift, is it correct to assume the combination of all 4 fields constitute a candidate key? It's good practice to be explicit about your keys.
Can an entity be without attributes?
Your Hospital relation does have an attribute - Hospital_ID, which represents an identity relation. Remember an attribute is a binary relation, and Hospital_ID -> Hospital_ID qualifies.
I am not sure it there should be a : relationship between the trust and patients?
What is the trust? It isn't indicated in your diagram at all.
Does a person assume that the first entity is a single unit, in this case a hospital has x relationships to....
Many-to-many relationships are decomposed into two or more one-to-many relationships, and in reading the cardinality indicators we tend to put the singular entity first, but this isn't a rule or a safe assumption. Be explicit about cardinalities.
Related
I'm designing an ER diagram for a social network and recently I got involved in an argument with my colleagues whether this part is right or wrong
ER DIAGRAM PROBLEM
Where Faqet(Pages) is connected with Shfrytezuesi(User) using three actions, pelqen is for storing likes, krijon faqe to know who created the page, and udheheq to store all page admins, so my question is
is this design wrong?
Can two tables be linked with more than one action, this is where I'm not certain
It's perfectly valid to have any number of relationships between any number of entity sets. My only concern with the diagram is that multiple role lines below Shfrytezuesi are merged into one - I recommend keeping them distinct.
Note that in the entity-relationship model, we don't link tables. That idea comes from the old network data model, in which rows represented entities, tables represented entity sets, and links between rows/tables represented relationships.
One disadvantage with that model is that it supports only directed binary relationships - many-to-many binary, ternary and higher relationships and relationships with attributes all required associative entities to be introduced. However, three binary relationships aren't equivalent to a ternary relationship, and not all relationships can be represented in binary data models.
The ER model supports n-ary relationships and attributes on relationships. Entity sets are represented by their primary keys and relationships by combinations of entity keys. Entity sets plus attributes form entity relations, relationship sets plus attributes form entity relations. These relations get mapped to tables. In practice, tables with the same primary keys get combined to reduce the number of tables, which means one-to-one and one-to-many relationships get combined into the relations for one of their associated entity sets.
Regardless of how tables are combined, attributes and relationships are represented by sets of columns. For example, based on your diagram, Pelqen would be represented as (FID PK, SID) (assuming SID is the primary key of Shfrytezuesi). These columns might have different names, e.g. SID might be renamed to AdminSID, especially if the relationship was combined into Faqet. The old network data model would view FID FK -> FID PK as a relationship, which as described above and below is a very limited kind of relationship and not the approach taken by the ER model.
Another disadvantage of the network data model is predetermined access paths, which means we have to navigate from table to table using the predefined relationships. This complicated queries and data processing significantly. This limitation was one of the main drivers for the development of the relational model, to which the ER model maps. The understanding of tables as relations in the RM enables us to construct and navigate arbitrary access paths using joins. So, we do link tables in the RM, but at query time and as needed rather than at design time. The ER model is used for conceptual design only and doesn't describe relationships between tables, only relationships between entity sets.
Now, the ER model isn't a complete and consistent logical model like the RM, but it is a significant improvement over the network data model. An even more rigorous approach than ER would be object-role modeling, but that's a different topic.
How can I represent my lookup tables in technical reports?
In other words, the ER model is used to represent a database,
but what about lookup tables?
To recover a conceptual model (entity sets, attributes and relationships) from a physical model (tables and columns), we first have to understand the logical model. This means understanding the domains and functional dependencies which are represented by the lookup table.
Lookup table is a common term which can mean different things. I generally understand it as a table which represents a domain with a surrogate key, and associates it with a name and/or a few other attributes. In the ER model, these would be simple entity relations, and leaves / terminal nodes in the graph of entity sets.
If a lookup table records facts about only one type of thing (represented by the key of the lookup table), then you can represent that type as an entity set (rectangle) with an attribute (oval) for each dependent column, and draw relationships (diamonds) to connect it to other entity sets as required. Look for foreign key columns / constraints in other tables to find these relationships.
For example, consider the following physical model:
CarMake and CarModel are examples of lookup tables. This isn't a very good model, since in the real world CarModelId determines CarMakeId, while the model treats them as independent elements in CarSales. However, since the point of the example is to focus on lookup tables, I'll use it as is.
In this case, CarMake and CarModel describe a single entity set each. Their functional dependencies are CarMakeId -> CarMakeName and CarModelId -> CarModelName. In CarSales, we've got CarSaleId -> RegNumber, Price, SoldOn (attributes) and CarSaleId -> CarMakeId, CarModelId (relationships).
In this case our ER model is similar to the physical model:
However, in some cases, you may find multiple types of things combined into one lookup table due to the similar physical structure. This doesn't affect the logical or conceptual models, but makes it more complicated to recover since we have to understand how the table is used to unpack it.
As i know optionality means the minimum cardinality of a relationship which is denoted as optional to optional, mandatory to optional, mandatory to mandatory..
And Participation denoted as bold line and a normal line.
In the Internet some refer participation as the dependency of the entity to the relationship which is also looks like identifying and non identifying relationship.
and some refer it as the minimum cardinality
What is the correct definitions of those relationships and what is the difference..
Let's start with definitions and examples of each of the concepts:
Total and partial participation:
Total participation (indicated by a double or thick association line) means that all the entities in an entity set must participate in the relationship. Partial participation (indicated by a single thin line) means that there can be entities in the entity set that don't participate in the relationship.
Medicine participates totally in the Produce relationship, meaning that Medicine can't exist unless Produced by a Laboratory. In contrast, a Laboratory can exist without Producing Medicine - Laboratory participates partially in the Produce relationsip.
Mandatory and optional roles:
In a relationship, roles can be optional or mandatory. This affects whether a relationship instance can exist without an entity in a given role. Mandatory roles are indicated with a solid association line, optional roles are indicated with a dotted line.
Roles aren't often talked about in database tutorials, but they're an important concept. Consider a marriage - a relationship with two mandatory roles filled by the same entity set. In most relationships, the entity sets also define the roles, but when an entity set appears multiple times in a single relationship, we distinguish them in different roles.
In the example above, a Patient can Purchase Medicine with or without a Prescription. A Purchase can't exist without a Patient and Medicine, but a Prescription is optional (overall, though it may be required in specific cases).
Identifying relationship / weak entity:
A weak entity is an entity that can't be identified by its own attributes and therefore has another entity's key as part of its own. An identifying relationship is the relationship between a weak entity and its parent entity. Both the identifying relationship and the weak entity are indicated with double borders. Weak entity sets must necessarily participate totally in their identifying relationship.
In this example, a Prescription contains LineItems which are identified by the Prescription's key and a line number. In other words, the LineItems table will have a composite key (Prescription_ID, Line_Number).
For examples of non-identifying relationships, see the previous examples. While Medicine participates totally in the Produce relationship, it has its own identity (e.g. a surrogate key, though I didn't indicate it). Note that surrogate keys always imply regular entities.
Mandatory/optional vs total/partial participation
Mandatory or optional roles indicate whether a certain role (with its associated entity set) is required for the relationship to exist. Total or partial participation indicate whether a certain relationship is required for an entity to exist.
Mandatory partial participation: See above: A Laboratory can exist without producing any medicine, but Medicine can't be Produced without a Laboratory.
Mandatory total participation: See above: Medicine can't exist without being Produced, and a Laboratory can't Produce something unspecified.
Optional partial participation: See above: A Prescription can exist without being Purchased, and a Purchase can exist without a Prescription.
That leaves optional total participation, which I had to think about a bit to find an example:
Some Patients Die of an unknown Cause, but a Cause of death can't exist without a Patient Dying of it.
Total/partial participation vs identifying/non-identifying relationships
As I said before, weak entity sets always participate totally in their identifying relationship. See above: a LineItem must be Contained in a Prescription, it's identity and existence depends on that. Partial participation in an identifying relationship isn't possible.
Total participation doesn't imply an identifying relationship - Medicine can't exist without being Produced by a Laboratory but Medicine is identified by its own attributes.
Partial participation in a non-identifying relationship is very common. For example, Medicine can exist without being Purchased, and Medicine is identified by its own attributes.
Mandatory/optional vs identifying/non-identifying relationships
It's unusual for a relationship to have less than two mandatory roles. Identifying relationships are binary relationships, so the parent and child roles will be mandatory - the Contain relationship between Prescription and LineItem can't exist without both entities.
Optional roles are usually only found on ternary and higher relationships (though see the example of patients dying of causes), and aren't involved in identification. An alternative to an optional role is a relationship on a relationship:
By turning Purchase into an associative entity, we can have it participate in a Fill relationship with Prescription. To maintain the same semantics as above I specified that a Purchase can only Fill one Prescription.
Physical modeling
If we translate from conceptual to physical model (skipping logical modeling / further normalization), making separate tables for each entity and relationship, things look pretty similar, though you have to know how to read the cardinality indicators on the foreign key lines to recover the ER semantics.
However, it's common to denormalize tables with the same primary keys, meaning one-to-many relationships are combined with the entity table on the many side:
A relationship is physically represented as two or more entity keys in a table. In this case, the entity keys - patient_id and cause_of_death_id are both found in the Patient table. Many people think the foreign key line represents the relationship, but this comes from confusing the entity-relationship model with the old network data model.
This is a crucial point - in order to understand different kinds of relationships and constraints on relationships, it's essential to understand what relationships are first. Relationships in ER are associations between keys, not between tables. A relationship can have any number of roles of different entity sets, while foreign key constraints enforce a subset constraint between two columns of one entity set. Now, armed with this knowledge, read my whole answer again. ;)
I hope this helps. Feel free to ask questions.
I am an ICS student and I have been given two questions.
1.) List all the Functional Dependencies that hold for the database.
2.) For each relation in your relational schema write down whether the relation is in BCNF or 3NF and if not give a violating FD.
I'm just having problems understanding the relationship between functional dependencies and the ER Diagram. I've watched a few videos online but I'm still getting stuck on how to answer the two above questions and would appreciate some help in finding the right direction.
Below is an ER diagram and I was hoping someone could give some examples on how to start from here.
For each entity set (e.g. Department), each attribute is an FD (e.g. Department Name -> Location).
For each relationship set (e.g. Offers), there's an FD from the combination of keys of "many" entities to each of the keys of "one" entities (e.g. Course_ID -> Department Name)
I'm new to ER diagrams. I noticed that draw.io (which was recommended on Stackoverflow) does not have a one (optional) to one (mandatory) relationship.
Let's say, I have two tables "user" (id, affiliate_id) and "affiliate" (id). There doesn't have to be an affiliate, in which case user.affiliate_id would be null.
However, if there is an affiliate, then user.affiliate_id will link to affiliate.id.
So wouldn't that be a one (optional) to one (mandatory) relationship?
PS: I was thinking that maybe user.affiliate_id must not be null in a strict sense. However, it doesn't break the foreign key constraints (at least for SQLite 3).
I think you are describing a one-to-many relationship. One user can (optionally) be associated to one affiliate, but the same affiliate can be associated to more than one user.
Or am I misunderstanding?
Yes, you are right, that would be a zero/one (or zero/many) to one relationship type, which has to be shown in the diagram. There are different notations for ER diagrams (and it's therefore, in fact, preferable to use UML class diagrams). For instance, in the notation used by Oracle the optional end of the connection line representing the relationship type is annotated with both a zero and a one symbol. In UML, the annotation of the optional association end would be 0..1 (if single-valued) or 0..* (if many-valued).