My Entity Relationship Diagram
My ER diagram designed for the Orders database about customers and their orders for
a company. Each item
in the database must have an “owning” salesman, whether or not it is being ordered.
With that being said I was wondering whether there were any issues with my diagram? What do you suggest I should change?
Should I remove the customer and salesman attributes?
I not sure but I think in your the Address Entity is extra its a attribute customer only so why you create address as a separate attribute.
Please refer the attach image to correct your different relationship with attributes.
Related
I have the following ERD:
ER Diagram
I need to convert this into relational schema but I have some doubts on where the attribute "since" would belong. I know how 1-M relationships work but I am confused by the attribute since. Does a new table Company-Employee need to be created where it would hold the Company id, emp id and since?
Please let me know thank you.
As you have diagrammed it, the Since attribute describes the relationship, not the employee or the company. There's nothing wrong with that, although some experts maintain that attributes must describe entities and not relationships.
When you go to design a relational schema, both entities and relationships become relations (or, as I prefer, "tables"). Your only question seems to be whether there has to be a junction table between the Employee table and the Company table.
You can get away with just two tables. You can stuff both the CompanyId and the Since columns into the Employee table, because they will be single valued. There may be other considerations that lead you to decompose the two tables, but you don't have to do it just to represent the data.
Can someone tell me the easy way to explain the differentiation between an entity and a table in database?
Entity is a logical concept of relational database model. And table is used to express it, but there is a slight difference. Table expresses not only entities, but also relations.
For example, assume that you want to make a database of projects and employees of a company. Entity is a unit of information that has meanings by itself. In this case, there will be two entities - "Project" and "Employee". Each entity has its own attributes.
In relational DB model, there is another idea, 'relation'. If employees participate in several projects, then we can say that there is a relation with a name 'works_on'.
Sometimes, relation can have its own attribute. In this case, 'works_on' relation can have attribute 'start_date' and so on. And if this relation is M:N relation(Like this case: In project 1, there are 5 employees. Employee A works on two projects.), then you have to make an extra table to express this relation. (If you don't make an extra table when the relation is M:N, then you have to insert too many duplicated rows into both 'Project' and 'Employee' table.)
CREATE TABLE works_on(
employee,
project_id,
start_date
)
An entity resides in a table, it is a single set of information, i.e: if you have a database of employees, then an employee is an entity. A table is a group of fields with certain parameters.
Basically everything is stored in a table, entities goes into tables.
In a relational database the concept is the same. An entity is a table.
In OOP (Oriented Object Programming) there is a nice article in Oracle docs:
In general terms, entity objects encapsulate the business policy and
data for
the logical structure of the business, such as product lines,
departments, sales, and regions
business documents, such as invoices, change orders, and service
requests
physical items, such as warehouses, employees, and equipment
Another way of looking at it is that an entity object stores the
business logic and column information for a database table (or view,
synonym, or snapshot). An entity object caches data from a database
and provides an object-oriented representation of it.
Depending on how you want to work, you can create entity objects from
existing database tables (reverse generation) or define entity objects
and use them to create database tables (forward generation).
There is little difference between an entity and a table, but first we should define the concepts of “tuple” and “attribute”. I want to express those concepts with a table.
Here is an example of a table. As you can see it has some columns. Each column represents an attribute and each line represents a tuple(row). This is the employee table. In this example, the table is being used for representing an entity which is employee. However, if we create a new table named superior to specify the superiority relationship between those employees, it would be a table that represents a relation. In summary, we can use tables for representing both the entities and relations so entities and tables are not the same.
Consider the following Relational Schema:
I am trying to fully Normalize (In Third Normal Form) and determine the functional dependencies. However, with endless research, I cannot get around on how to:
Fully Normalize the Relational Schema
Determine the Functional Dependencies
How would I go about this?
An employee can be a customer, and may become a manager one day. Use the Party Model. "Employee" or "Customer" should be a role played by a Party. A Party hasMany Roles
People can have no address, one address, or multiple addresses. People can share the same address. Use an Address table, and a PersonAddress junction table. Same with phone numbers.
You'll probably want to have individual customers and organization customers (companies or shared accounts). Use the Party Model.
Why does Branch not use a BranchId when all the other tables use id columns?
Are you sure a Customer is assigned to an Employee? What if the employee is on vacation?
Why "city" and "town" in Branch?
Is there such a thing? I'm not implementing anything, I'm just creating an E-R Diagram from it. Here is a simple example:
ENT(Ent_ID, Group_IDs)
GROUP(Group_ID, Att)
The attribute Group_ID would have an one-to-many relationship with different instances of GROUP. (Is the word instance correct here?)
P.s: I know I could create a third entity with Ent_ID and Group_ID as attributes to make the relations if I was implementing it, but I don't know if this has to be specified in the diagram.
The way I understand your example, you have a one-to-many relation:
Each GROUP instance can have many ENT instances related, but every ENT instance is related to one and only one GROUP instance.
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