ENTITY RELATIONSHIP DIAGRAM An entity-relationship diagram is a data modeling technique that creates a graphical representation of the entities, and

the relationships between entities, within an information system The three main components of an ERD are: The entity is a person, object, place or event for which data is collected. For example, if you consider the information system for a business, entities would include not only customers, but the customer's address, and orders as well. The entity is represented by a rectangle and labelled with a singular noun. The relationship is the interaction between the entities. In the example above, the customer places an order, so the word "places" defines the relationship between that instance of a customer and the order or orders that they place. A relationship may be represented by a diamond shape, or more simply, by the line connecting the entities. In either case, verbs are used to label the relationships. The cardinality defines the relationship between the entities in terms of numbers. An entity may be optional: for example, a sales rep could have no customers or could have one or many customers; or mandatory: for example, there must be at least one product listed in an order. There are several different types of cardinality notation; crow's foot notation, used here, is a common one. In crow's foot notation, a single bar indicatesone, a double bar indicates one and only one (for example, a single instance of a product can only be stored in one warehouse), a circle indicates zero, and a crow's footindicates many. The three main cardinal relationships are: oneto-one, expressed as 1:1; one-to-many, expressed as 1:M; and manyto-many, expressed as M:N.

The steps involved in creating an ERD are:

Identify the entities. Determine all significant interactions. Analyze the nature of the interactions.

Draw the ERD.

Define an entity
An entity is a grouping of things with rules or data in common. An entity often represents a group of people (eg children, applicants, stakeholders) but it can also represent a group of objects (eg textbooks), activities (eg assignments) or concepts (eg school terms). By defining entities, the same set of rules can be used for multiple instances of the same type, and rules can be written which relate to all of those instances. A member of the entity group is called an entity instance. For example, if a family had 2 children, Sarah and Peter, Sarah would be one instance of "the child" entity and Peter would be another instance of "the child" entity. By creating an entity to represent "the child", information such as the child's age can be collected for each child. We can also infer attributes from this data just as we can in a normal rule. Therefore, the attribute "the child is a young child" can hold a different value for each child, depending on the child's age. For instance, if we had a rule:
the child is a young child if the child's age < 8

Different types of entities

There are two types of entities: regular entities and the global entity.

Entities
An entity can have zero or more entity instances. For example, children in a family, applicants on an application form, taxable events in a tax period. Using entities you can apply the same rules, or collect the same data, for multiple instances of an entity. An attribute of an entity may hold one value at a time during an investigation for each instance of the entity. That attribute may have as many values as there are instances of the entity, and will only operate within the context of that entity instance.

Global Entities
Not all information relevant to your rules may belong to a particular entity. As such, Oracle Policy Modeling has a global entity which acts as a catch-all for information that does not belong to any other entity. For example "the sun is shining" is a global attribute that does not belong to the entity "the family, "the child" and so forth. An attribute of a global entity may only hold one value at a time during an investigation, and that value persists across the entire rulebase, common to all entities and instances of entities.

The global entity is the default location of attributes. If you do not create entities in your rulebase, or if you create an attribute which does not belong to another entity, the attribute will be stored in the global entity. The following diagram shows how instances of a child in a family situation have entity attributes:

In the diagram, both children are in the same family and are going to the same holiday destination, but each has their own distinct properties (entity attributes), such as name, age and favorite animal. Attributes

In general, an attribute is a property or characteristic. Color, for example, is an attribute of your hair. In using or programming computers, an attribute is a changeable property or characteristic of some component of a program that can be set to different values.
In DBMS a table contains one or more columns there columns are the attribute in DBMS FOR EXAMPLE---say you have a table named "employee information"which have the following columns ID,NAME,ADDRESSTHEN id ,name address are the attributes of employee..................

Simple and Composite Attribute Simple attribute that consist of a single atomic value. A composite attribute is an attribute that can be further subdivided. For example the attribute ADDRESS can be subdivided into street, city, state, and zip code. A simple attribute cannot be subdivided. For example the attributes age, sex etc are simple attributes.

Simple Attribute: Attribute that consist of a single atomic value. Example: Salary, age etc

Composite Attribute : Attribute value not atomic. Example : Address : House_no:City:State Name : First Name: Middle Name: Last Name

Single Valued and Multi Valued attribute A single valued attribute can have only a single value. For example a person can have only one 'date of birth', 'age' etc. That is a single valued attributes can have only single value. But it can be simple or composite attribute.That is 'date of birth' is a composite attribute , 'age' is a simple attribute. But both are single valued attributes. Multivalued attributes can have multiple values. For instance a person may have multiple phone numbers,multiple degrees etc.Multivalued attributes are shown by a double line connecting to the entity in the ER diagram. Single Valued Attribute: Attribute that hold a single value Example1: Age Exampe2: City Example3:Customer id Multi Valued Attribute: Attribute that hold multiple values. Example1: A customer can have multiple phone numbers, email id's etc Example2: A person may have several college degrees Stored and Derived Attributes The value for the derived attribute is derived from the stored attribute. For example 'Date of birth' of a person is a stored attribute. The value for the attribute 'AGE' can be derived by subtracting the 'Date of Birth'(DOB) from the current date. Stored attribute supplies a value to the related attribute. Stored Attribute: An attribute that supplies a value to the related attribute. Example: Date of Birth Derived Attribute: An attribute thats value is derived from a stored attribute. Example : age, and its value is derived from the stored attribute Date of Birth. Value set

The value set is a collection (or) container of values. When ever the value set associated with any report parameters. It provides list of values to the end user to accept one of the values as report parameter value. If the list of values needed to be dynamic and ever changing and define a table based values set.

Entity set
Entity set is a set of entitiesof the same type that share same properties eg.set of all persons, tress, class student names etc.

Relationship Types

Relationship types associate entity types. They are pictured by Diamond nodes, and edges connecting to the related entity types.

A relationship set is the collection of instances (i.e., relationships between objects) represented by a relationship type.

Relationship types may associate an entity type with itself. In such a case, the roles of the entity types in the relationship type are listed on the edges, and the relationship is said to be recursive.

2.5 Attributes

Entity types and relationship types might have attributes.

The value set, or domain, of an attribute is the set of values that may be assigned to the attribute. Mathematically, attribute : entity power-set(domain)

Atomic attribute types, pictured by oval nodes

Composite attribute types, achieved by concatenating simpler attribute types, pictured by trees of atomic attributes

Multivalued attribute types

A blue and red shirt

Derived attribute types displayed in dashed ovals

A age from birth date

2.6 Keys and Weak Entity Types

Key attribute types, identify the instances, may be consisted of more than one attribute, displayed with underlined attribute type names

Weak entity types have no keys. Displayed by double-rectangular nodes

To be identified, instances of weak entity type require an identifying relationship type that relates them to an identifying entity type. Such relations are displayed by double-diamond nodes

Weak entity types typically have partial key for distinguishing their instances.

Regular entity types with keys are sometimes called strong entity types.
2.7 Structural Relationship Constraints Participation constraint

specifies whether the existence of an entity depends on its being related to another entity via the relationship type Total participation constraints require the participation of every entity the relationship (displayed by double line). Also called existence dependency. Partial participation constraints (displayed by a single line).

Cardinality ratio constraint

Specifies the number of relationship instances an entity can participate in Displayed on the diamonds

Cardinality constraint Specifies lower and upper bounds on the number of relationships each entity can participate in.

Summary of Notation Entity

Weak Entity Relationship

Identifying Relationship Attribute Key Attribute Multivalued Attribute Composite Attribute Derived Attribute Total participation of E2 in R Cardinality ratio 1 : N for E1 : E2 in R Structural constraint (min,max) on participation

of E in R

DATA MODEL Data models are tools used in analysis to describe the data requirements and assumptions in the system from a top-down perspective. They also set the stage for the design of databases later on in the SDLC. There are three basic elements in ER models: Entities are the "things" about which we seek information. Attributes are the data we collect about the entities. Relationships provide the structure needed to draw information from multiple entities. Generally, ERD's look like this:

adapted from another professor.

Developing an ERD
Developing an ERD requires an understanding of the system and its components. Before discussing the procedure, let's look at a narrative created by Professor Harman.

Consider a hospital: Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two. Heathcare assistants also attend to the patients, a number of these are associated with each ward. Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time. The system must record details concerning patient treatment and staff

payment. Some staff are paid part time and doctors and care assistants work
varying amounts of overtime at varying rates (subject to grade). The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put).

How do we start an ERD?

1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation; identified in the narrative (see highlighted items above). 2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity ______ entity); identified in the narrative (see highlighteditems above). 3. Add attributes to the relations; these are determined by the queries,and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers. What questions can we ask? a. Which doctors work in which wards? b. How much will be spent in a ward in a given week? c. How much will a patient cost to treat? d. How much does a doctor cost per week? e. Which assistants can a patient expect to see? f. Which drugs are being used? 4. Add cardinality to the relations Many-to-Many must be resolved to two one-to-manys with an additional entity Usually automatically happens Sometimes involves introduction of a link entity (which will be all foreign key) Examples: Patient-Drug 5. This flexibility allows us to consider a variety of questions such as: a. Which beds are free? b. Which assistants work for Dr. X? c. What is the least expensive prescription? d. How many doctors are there in the hospital? e. Which patients are family related? 6. Represent that information with symbols. Generally E-R Diagrams require the use of the following symbols:

Functional dependency
The concept of functional dependency (also known as normalization was introduced by professor Codd in 1970 when he defined the first three normal forms (first, second and third normal forms). Normalization is used to avoid or eliminate the three types of anomalies (insertion, deletion and update anomalies) which a database may suffer from. These concepts will be clarified soon, but first let us define the first three normal forms.
A functional dependency (FD) is a constraint between two sets of attributes in a relation from a database. A functional dependency occurs when one attribute in a relation uniquely determines another attribute. This can be written A -> B which would be the same as stating "B is functionally dependent upon A.
Functional Dependency can be classified as follows:

Full Functional dependency Indicates that if A and B are attributes (columns) of a table, B is fully functionally dependent on A if B is functionally dependent on A, but not on any proper subset of A. Partial Functional Dependency Indicates that if A and B are attributes of a table , B is partially dependent on A if there is some attribute that can be removed from A and yet the dependency still holds. Transitive Functional Dependency: A condition where A , B and C are attributes of a table such that if A is functionally dependent on B and B is functionally dependent on C then C is Transitively dependent on A via B

Fourth normal form (4NF) is a normal form used in database normalization. Introduced by Ronald Fagin in 1977, 4NF is the next level of normalization after BoyceCodd normal form (BCNF). Whereas the second, third, and BoyceCodd normal forms are concerned with functional dependencies, 4NF is concerned with a more general type of dependency known as a multivalued dependency.

Fourth normal form requires that a table be BCNF and contain no multi-valued dependencies. 4NF solves the problem of multivolume dependencies, which we would encounter with our above Sales table when a customer purchased multiple products with a single order - we would have numerous rows that were dependent on one another without any clear definition of that dependency in the table. Fifth normal form, also known as join-projection normal form (JPNF), states that no non-trivial join dependencies exist. 5NF states that any fact should be able to be reconstructed without any anomalous results in any case, regardless of the number of tables being joined. A 5NF table should have only candidate keys and it's primary key should consist of only a single column. The problem with these forms is the size of the joins that are required to reconstruct any non-trivial data.We can rely on views and procedures to simplify them but the underlying data still ends up very complex. There are also performance issues to

consider - which is why 4NF and 5NF are often academic. In most cases, 3NF (or BCNF) are ideal.