Lecture On Database Analysis and Design By- Jesmin Akhter Lecturer, IIT, Jahangirnagar University

MODELING THE RULES OF THE ORGANIZATION Prepared by Jesmin Akhter, Lecturer, IIT,JU

Overview of Business Rules Business rules are important in data modeling because they govern how data are handled and stored. Basic business rules are data names and definitions. Thoroughly capturing and structuring business rules, then enforcing them through database technologies, helps to ensure that information systems work right.

Prepared by Jesmin Akhter, Lecturer, IIT,JU Data Names and Definitions Fundamental to understanding and modeling data are naming and defining data objects. In the entity-relationship notation, entities, relationships, and attributes are defined with clear and distinct names and definitions. there are some general guidelines about naming any data object. Data names should Relate to Business, not Technical (Hardware or Software) Characteristics; so, Customer is a good name, but File10, Bit7 are not good names.. Be Meaningful almost to the point of being self-documenting.

Prepared by Jesmin Akhter, Lecturer, IIT,JU Data Names Be Unique from the name used for every other distinct data object; words should be included in a data name if they distinguish the data object from other similar data objects (e.g., HomeAddress versus CampusAddress). Be Readable, so that the name is structured as the concept would most naturally be said (e.g., GradePointAverage is a good name. Be Composed of Words; each organization often chooses a vocabulary from which significant words in data names must be chosen. Alternative, or alias names, also can be used as can approved abbreviations (e,g” CUST for Customer), and you may be encouraged to use abbreviations so that data names are short enough to meet maximum length limits of database technology. Be Repeatable, meaning that different people or the same person at different times should develop exactly or almost the same name; this often means that there is a standard hierarchy or pattern for names (e,g., the birth date of a student would be StudentBirthDate and the birth date of an employee would be EmployeeBirthDate).

Data Modeling using the Entity Relationship Model Prepared by Jesmin Akhter, Lecturer, IIT,JU

ER Model Concepts Entities and Attributes –Entities are specific objects or things in the mini-world that are represented in the database. For example EMPLOYEE, DEPARTMENT, PERSON, COMPANY. –Attributes are properties used to describe an entity. For example an EMPLOYEE entity may have a Name, Id, Address, Sex, BirthDate. –A specific entity will have a value for each of its attributes. For example a specific employee entity may have Name='John Smith', Id=' ', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘ –Each attribute has a value set (or data type) associated with it – e.g. integer, float string, date-type, enumerated type, …

Types of Attributes Simple –Each entity has a single atomic value for the attribute. Attribute that are not divisible are called simple or atomic attributes. For example, id or Sex. Composite –The attribute may be composed of several components. For example, Address (Apt#, House#, Street, City, State, ZipCode, Country) or Name (FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite. Multi-valued –An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.

An entity instance is a single occurrence of an entity type. Figure below illustrates the distinction between an entity type and two of its instances. An entity type is described just once (using metadata) in a database, whereas many instances of that entity type may be represented by data stored in the database. For example, there is one EMPLOYEE entity type in most organizations, but there may be hundreds (or even thousands) of instances of this entity type stored in the database.. Prepared by Jesmin Akhter, Lecturer, IIT,JU Entity Type Versus Entity Instance

Prepared by Jesmin Akhter, Lecturer, IIT,JU Strong Versus Weak Entity Types Most of the basic entity types to identify in an organization are classified as strong entity types. A strong entity type is one that exists independently of other entity types. Examples include STUDENT, EMPLOYEE, AUTOMOBILE, and COURSE. Instances of a strong entity type always have a unique characteristic (called an identifier)-that is, an attribute or combination of attributes that uniquely distinguish each occurrence of that entity. A weak entity type is an entity type whose existence depends on some other entity type. A weak entity type has no business meaning in an E-R diagram without the entity on which it depends. The entity type on which the weak entity type depends is called the identifying owner (or simply owner for short). A weak entity type does not have its own identifier. Generally, on an E-R diagram, a weak entity type has an attribute that serves as a partial identifier A full identifier will be formed for the weak entity by combining the partial identifier with the identifier of its owner.

A composite attribute is an attribute, such as Address, that has meaningful component parts. Figure shows the notation that we use for composite attributes applied to this example. Simple (or atomic) attribute: An attribute that cannot be broken down into smaller components that are meaningful to the organization. For example, all of the attributes associated with AUTOMOBILE are simple: Vehicle_ID, Color, Weight and Horsepower. Prepared by Jesmin Akhter, Lecturer, IIT,JU Simple Versus Composite Attributes EMPLOYEE Employee_Address (StreeCAddress, City, State, PostaLCode)

Single valued attribute: An attribute that may take on only one value for a given entity (or relationship) instance. Ex. Age is a single valued attribute of a person. Multivalued attribute: An attribute that may take on more than one value for a given entity (or relationship) instance Ex. Colors attribute for a car, Cars with one color have a single valued, where as two tone cars have two values for colors. Ex. College degree Prepared by Jesmin Akhter, Lecturer, IIT,JU Single Valued Versus Multivalued Attributes

Some attribute values can be calculated or derived from other related attribute values that are stored in the database. For example, suppose that for an organization, the EMPLOYEE entity type has a Date_Employed attribute. If users need to know how many years a person has been employed, that value can be calculated using Date_Employed and today's date. Ex. Date_Employed, BirthDate. A derived attribute is an attribute whose values can be calculated from related attribute values (plus possibly data not in the data base, such as today's date, the current time, or a security code provided by a system user). Ex. Age attribute of a person. Prepared by Jesmin Akhter, Lecturer, IIT,JU Stored Versus Derived Attributes EMPLOYEE Employee_Name(... ) PayroILAddress(... ) Date_Employed {Skill} (Years_Employed)

Entity Types and Key Attributes An entity type defines a collection (or sets)of entities that have the same attributes but each entity has its own value. For example, the EMPLOYEE entity type or the PROJECT entity type. An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, Id_no of EMPLOYEE. A key attribute may be composite. For example, VehicleTagNumber is a key of the CAR entity type with components (Number, State). An entity type may have more than one key. For example, the CAR entity type may have two keys: –VehicleIdentificationNumber (popularly called VIN) and –VehicleTagNumber (Number, State), also known as license_plate number.

ENTITY SET corresponding to the ENTITY TYPE CAR car 1 ((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1999, {red, black}) car 2 ((ABC 123, NEW YORK), WP9872, Nissan 300ZX, 2-door, 2002, {blue}) car 3 ((VSY 720, TEXAS), TD729, Buick LeSabre, 4-door, 2003, {white, blue}). CAR Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, {Color} The collection of all entities of a particular entity type in the database at any point in time is called an entity set. Use the same name as entity type. CAR indicate entity type and current set of all CAR entities in the database.

NOTATION OF ER-DIAGRAM Meaning ENTITY WEAK ENTITY RELATIONSHIP IDENTIFYING RELATIONSHIP ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE TOTAL PARTICIPATION OF E 2 IN R CARDINALITY RATIO 1:N FOR E 1 :E 2 IN R STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R Symbol E1E1 R E2E2 E1E1 R E2E2 R (min,max) E N

ER DIAGRAM – Entity Types are: EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Relationships and Relationship Types A relationship relates two or more distinct entities with a specific meaning. For example, EMPLOYEE John Smith works on the ProductX PROJECT or EMPLOYEE Franklin Wong manages the Research DEPARTMENT. Relationships of the same type are grouped or typed into a relationship type. For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate. The degree of a relationship type is the number of participating entity types. Both MANAGES and WORKS_ON are binary relationships.

Example relationship instances of the WORKS_FOR relationship between EMPLOYEE and DEPARTMENT e 1 e 2 e 3 e 4 e 5 e 6 e 7 EMPLOYEE r1r2r3r4r5r6r7r1r2r3r4r5r6r7 WORKS_FOR d 1 d 2 d 3 DEPARTMENT

Example relationship instances of the WORKS_ON relationship between EMPLOYEE and PROJECT e 1 e 2 e 3 e 4 e 5 e 6 e 7 r1r2r3r4r5r6r7r1r2r3r4r5r6r7 p 1 p 2 p 3 r8r8 r9r9 EMPLOYEEWORKS_ONPROJECT

Relationships and Relationship Types (2) More than one relationship type can exist with the same participating entity types. For example, MANAGES and WORKS_FOR are distinct relationships between EMPLOYEE and DEPARTMENT, but with different meanings and different relationship instances.

ER DIAGRAM – Relationship Types are: WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Chapter 3-23 Weak Entity Types An entity that does not have a key attribute Example: Suppose that a DEPENDENT entity is identified by the dependent’s first name and birhtdate, and the specific EMPLOYEE that the dependent is related to. DEPENDENT is a weak entity type with EMPLOYEE as its identifying entity type via the identifying relationship type EPENDENT_OF

Chapter 3-24 Weak Entity Type is: DEPENDENT Identifying Relationship is: DEPENDENTS_OF

Constraints on Relationships Constraints on Relationship Types –( Also known as ratio constraints ) – Maximum Cardinality One-to-one (1:1) One-to-many (1:N) or Many-to-one (N:1) Many-to-many –Minimum Cardinality (also called participation constraint or existence dependency constraints) zero (optional participation, not existence- dependent) one or more (mandatory, existence-dependent)

Many-to-one (N:1) RELATIONSHIP e 1 e 2 e 3 e 4 e 5 e 6 e 7 EMPLOYEE r1r2r3r4r5r6r7r1r2r3r4r5r6r7 WORKS_FOR d 1 d 2 d 3 DEPARTMENT

Many-to-many (M:N) RELATIONSHIP e 1 e 2 e 3 e 4 e 5 e 6 e 7 r1r2r3r4r5r6r7r1r2r3r4r5r6r7 p 1 p 2 p 3 r8r8 r9r9 EMPLOYEEWORKS_ON PROJECT