Tuesday

ER Modelling

This is based on Oracle. ER Modeling In an effective system, data is divided into discrete categories or entities. An entity relationship (ER) model is an illustration of various entities in a business and the relationships between them. An ER model is derived from business specifications or narratives and built during the analysis phase of the system development life cycle. ER models separate the information required by a business from the activities performed within a business. Although businesses can change their activities, the type of information tends to remain constant. Therefore, the data structures also tend to be constant. Benefits of ER Modeling • Documents information for the organization in a clear, precise format . • Provides a clear picture of the scope of the information requirement. • Provides an easily understood pictorial map for the database design . • Offers an effective framework for integrating multiple applications . Key Components • Entity: A thing of significance about which information needs to be known. Examples are departments, employees, and orders. • Attribute: Something that describes or qualifies an entity. For example, for the employee entity, the attributes would be the employee number, name, job title, hire date, department number, and so on. Each of the attributes is either required or optional. This state is called optionality. • Relationship: A named association between entities showing optionality and degree. Examples are employees and departments, and orders and items. Entities To represent an entity in a model, use the following conventions: • Soft box with any dimensions • Singular, unique entity name • Entity name in uppercase • Optional synonym names in uppercase within parentheses: ( ) Attributes To represent an attribute in a model, use the following conventions: • Use singular names in lowercase. • Tag mandatory attributes, or values that must be known, with an asterisk: *. • Tag optional attributes, or values that may be known, with the letter o. Relationships Each direction of the relationship contains: • A label, for example, taught by or assigned to • An optionality, either must be or may be • A degree, either one and only one or one or more Note: The term cardinality is a synonym for the term degree. Each source entity {may be must be} relationship name {one and only one one or more} destination entity. Note: The convention is to read clockwise. Unique Identifiers A unique identifier (UID) is any combination of attributes or relationships, or both, that serves to distinguish occurrences of an entity. Each entity occurrence must be uniquely identifiable. • Tag each attribute that is part of the UID with a number symbol: # • Tag secondary UIDs with a number sign in parentheses: (#) Relating Multiple Tables • Each row of data in a table is uniquely identified by a primary key (PK). • You can logically relate data from multiple tables using foreign keys (FK). Relating Multiple Tables Each table contains data that describes exactly one entity. For example, the EMPLOYEES table contains information about employees. Categories of data are listed across the top of each table, and individual cases are listed below. Using a table format, you can readily visualize, understand, and use information. Because data about different entities is stored in different tables, you may need to combine two or more tables to answer a particular question. For example, you may want to know the location of the department where an employee works. In this scenario, you need information from the EMPLOYEES table (which contains data about employees) and the DEPARTMENTS table (which contains information about departments). With an RDBMS you can relate the data in one table to the data in another by using the foreign keys. A foreign key is a column or a set of columns that refer to a primary key in the same table or another table. You can use the ability to relate data in one table to data in another to organize information in separate, manageable units. Employee data can be kept logically distinct from department data by storing it in a separate table. Guidelines for Primary Keys and Foreign Keys • You cannot use duplicate values in a primary key. • Primary keys generally cannot be changed. • Foreign keys are based on data values and are purely logical, not physical, pointers. • A foreign key value must match an existing primary key value or unique key value, or else be null. • A foreign key must reference either a primary key or unique key column. Terminology Used in a Relational Database A relational database can contain one or many tables. A table is the basic storage structure of an RDBMS. A table holds all the data necessary about something in the real world, such as employees, invoices, or customers. The slide shows the contents of the EMPLOYEES table or relation. The numbers indicate the following: 1. A single row or table representing all data required for a particular employee. Each row in a table should be identified by a primary key, which allows no duplicate rows. The order of rows is insignificant; specify the row order when the data is retrieved. 2. A column or attribute containing the employee number. The employee number identifies a unique employee in the EMPLOYEES table. In this example, the employee number column is designated as the primary key. A primary key must contain a value, and the value must be unique. 3. A column that is not a key value. A column represents one kind of data in a table; in the example, the salary of all the employees. Column order is insignificant when storing data; specify the column order when the data is retrieved. 4. A column containing the department number, which is also a foreign key. A foreign key is a column that defines how tables relate to each other. A foreign key refers to a primary key or a unique key in the same table or in another table. In the example, DEPARTMENT_ID uniquely identifies a department in the DEPARTMENTS table. 5. A field may have no value in it. This is called a null value. In the EMPLOYEES table, only employees who have a role of sales representative have a value in the COMMISSION_PCT (commission) field. 6. A field can be found at the intersection of a row and a column. There can be only one value in it.