As we analyze an enterprise with our Business functions and entities - we then need to transfer that information into a Diagram - called the Entity-Relationship Diagram. This is a Data model that will help us design our databases properly. As any model - the E/R model has certain components. Following the "read me second" file, you will find a file titled "E/R diagram components". This file shows the various components - Entity (drawn as a rectangle - and is a Noun); Attributes (these are the fields that make up a particular entity (such as for PATIENT - you would have Patient_lastname, Patient_firstname, etc.); Relationships - these are actually drawn first as a connecting line between entities and we write the relationships (which will be a verb). We then need to determine how a particular Entity is "related" to another Entity - called Cardinality. There are four possible combinations for an entity to relate to another entity: mandatory one (written as two straight lines bisecting the relationships line); mandatory many (written as one straight bisecting line and a "less than" symbol); option one (written as a circle followed by a straight by-secting line); and option many (written as a circle followed by the "less than" symbol. These cardinalities mean that for one instance of an Entity (say one particular patient of the PATIENT entity) - how many MUST or SHOULD we have of the related Entity (say TREATMENT). So for Patient X - how many TREATMENT instances MUST or SHOULD we have. MUST means you have to have at least 1 instance of TREATMENT. MANY means you can have 1 or many TREATMENT instances for Patient X. For any given Patient we would probably select the cardinality relationship between the Entity - PATIENT and the Entity - TREATMENT as mandatory many relationships.
We also have what we call "relationship degrees" - an Entity may be related to itself - for instance - the entity EMPLOYEE may have a relationship with itself as "manages" - in other words, an EMPLOYEE may manage an EMPLOYEE (related to itself) - this is called a UNARY relationship. The most common relationship between two entities is binary - an entity is related to another entity. The third type of relationship is Ternary - where three entities are related through one relationship. (this is very rare and we really don't want to have these types of relationships).
We have various type of attributes (the fields that make up a particular entity). Again - for example: STUDENT (entity) Student_ID, Student_lastname, Student_firstname, Student_street, etc. are the attributes (fields) that make up STUDENT entity. We can have both required and optional attributes - in other words, some of the fields may or may not have data in them. We can also have a Composite Attribute - that is made up of sub-attributes. For example Address (is actually made up of Street, City, State, etc.). A Derived attribute is one that can be calculated from other attribute values. For example Age may be calculated from Current_date and Date_of_birth.
A very important attribute is called an Identifier - or "KEY" attribute. We have two types of key attributes - Primary Key attributes and Secondary Key attributes. The Primary Key attribute that you select MUST be unique (different) for each instance of your data. For instance, - Social_Security_number is a very good Primary Key attribute for entities such as PATIENT, STUDENT, EMPLOYEE. You choose which of your attributes (fields) will be your Primary Key attribute. You can then have secondary key attributes - such as Patient_lastname (however, the data won't be unique here for every instance that you have - in other words, we have many last names that are "Smith".