In database terms, an entity is a table that contains information pertinent to the database and holds information useful to its end user. An entity name is usually labeled at the top of a rectangle and is usually a noun. Underneath the name of the entity are subsets of more specific information relevant to the entity, called attributes. For example, if someone wanted to include a beach entity in a vacationers database, they may include attributes such as: beach name, city, country, rating, # of parking lots, etc. Beach would be the name of the entity and the more specific information would be the attributes, which make up the entit
There are several important characteristics to mention when explaining the purpose of different attributes. An attribute may be required or optional, which tells the user whether or not they have to input information into this field. A required attribute must contain a value and an optional may be left null if there is no information to be entered. The domain of an attribute gives the database user a choice of possible inputs that will be accepted into the database. For example, there may be a “type of computer” field in which the two input options are “PC” and “Mac.” Yet another feature of attributes is the users ability to use an identifier to identify the attribute, which uniquely identifies the entity, which it describes. For example, if an entity existed that provided information about students, a student id would be a good identifier instead of a first name because there are probably many students who share a first name.
Entities are connected using relationships. In other words, relationships represent different ways in which entities may be associated with one another and entities involved in relationships are called participants. Such relationships can usually be described using verbs. For example, a relationship may exist between a piece of bread and a toaster in which the toaster toasts the bread and the bread is toasted by the toaster. Both bread and toaster are participants and the relationship could be called “toasts” or “is toasted by” depending on which way you look at the relationship.
Weak Relationship – primary key of attribute ≠ primary key of second attribute.
Strong Relationship – primary key of attribute = primary key of second attribute.
Within the idea of participation two different types should be mentioned: Optional Participation and Mandatory Participation. Optional participation means simply that one entity does not require a corresponding entity, while mandatory participation does. Cardinality is another idea within database systems that provides more information on how entities associate with each other. Cardinality provides the minimum and maximum number of occurrences possible between certain entities. For example, a department of a company may have many managers, but a manager can only manage one department. In the case of this example, the cardinality from department to manager is zero to many because a department may have zero managers and may also have many. The cardinality from manager to department is zero to one because if a manager manages a department, he or she may only manage one.
The following link may provide very useful information. The link brings you to a database forum that addresses many relevant topics. This particular link will bring you directly to a page discussing entity relationships, but there are more topics: http://forums.databasejournal.com/showthread.php?t=49160
Some very useful information regarding entity relationships can be found at: http://www.umsl.edu/~sauterv/analysis/er/er_intro.html
Also, on the following link, good examples of entity relationships can be found: http://databases.about.com/cs/specificproducts/g/er.htm
On a broader scale, this link gives step-by-step instructions on creating a database: http://office.microsoft.com/en-us/visio/HP010181611033.aspx
