Attribute

· Characteristics of entities

· In Chen model, attributes are represented by ovals and are connected to entity rectangle with a line

· Each oval contains the name of attribute it represents

· In Crow’s Foot model, attributes are written in attribute box below entity rectangle

· Should be meaningful

· Rule of thumb is to prefix attribute with entity name

– i.e. CUSTOMER_NAME versus NAME

· Can be single valued

– An attribute that can have only a single value

– i.e. social insurance number

· Can be multi valued

– An attribute that can have many values

– i.e. an employee has many skills

Derived Attributes

· Attribute whose value may be calculated (derived) from other attributes

· Need not be physically stored within database

· Can be derived by using an algorithm

· Can show in the conceptual model

Null Value Attribute

· Attribute that doesn’t have any value for a record

Mandatory Value Attribute

· Attribute that must have a value

Record/Tuple

record

In the context of a relational database, a row—also called a record or tuple—represents a single, implicitly structured data item in a table. In simple terms, a database table can be thought of as consisting of rows and columns or fields. Each row in a table represents a set of related data, and every row in the table has the same structure.

For example, in a table that represents companies, each row would represent a single company. Columns might represent things like company name, company street address, whether the company is publicly held, its VAT number, etc.. In a table that represents the association of employees with departments, each row would associate one employee with one department.
The implicit structure of a row, and the meaning of the data values in a row, requires that the row be understood as providing a succession of data values, one in each column of the table. The row is then interpreted as a relvar composed of a set of tuples, with each tuple consisting of the two items: the name of the relevant column and the value this row provides for that column.

Each column expects a data value of a particular type. For example, one column might require a unique identifier, another might require text representing a person’s name, another might require an integer representing hourly pay in cents.

What Should an Entity Be?

• SHOULD BE:

– An object that will have many instances in the database

– An object that will be composed of multiple attributes

– An object that we are trying to model

• SHOULD NOT BE:

– A user of the database system

– An output of the database system (e.g. a report)

Key

Super Key

A superkey is an attribute or a set of attributes that uniquely identify the relation. That is, no two tuples have the same values on the superkey. By definition, a relation consists of a set of distinct tuples. The set of all attributes in the relation forms a superkey.

Candidate Key

A key K is a minimal superkey, meaning that any proper subset of K is not a superkey. It is possible that a relation has several keys. In this case, each of the keys is called a candidate key.

Primary Key

The primary key is one of the candidate keys designated by the database designer. The primary key is often used to identify tuples in a relation.

The primary key constraint specifies that the primary key value of a tuple cannot be null and no two tuples in the relation can have the same value on the primary key. The DBMS enforces the primary key constraint. For example, if you attempt to insert a record with the same primary key as an existing record in the table, the DBMS would report an error and reject the operation.

Foreign Key

In a relational database, data are related. Tuples in a relation are related and tuples in different relations are related through their common attributes. Informally speaking, the common attributes are foreign keys. The foreign key constraints define the relationships among relations.

External Key

The external key is a lexical attribute (or compilation lexical attribute) that the values always identify an object instance.

ERD(ENTITY RELATIONAL DIAGRAM)

In software engineering, an Entity-Relationship Model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion.

What’s Differences between DFD (DATA FLOW DIAGRAM) and ERD(ENTITY RELATIONAL DIAGRAM)?

· DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage. Where as

The ERD, which represents the entity model, shows what the database or system will look like but doesn’t explain how to implement it. An ERD is vendor-neutral. It groups data into entities and relates the entities to one another based on business rules. An entity is something that has substance and about which you want to store data. A business rule is a policy or procedure that a business enforces. It describes how the business operates

ERD Elements

Entity

An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world.^[3]

An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used, following Chen we should really distinguish between an entity and an entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term.

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. Entities are represented as rectangles.

Relationship

A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship.

Relationship Degree

Degree of a Relationship is the number of entity types that participate in it

Attribute

Attribute is Characteristics of both entities and realationship

Cardinality

the number of instances of one entity that can or must be associated with each instance of another entity.

Degree of a Relationship

Degree of a Relationship is the number of entity types that participate in it

· Unary Relationship

– Association is maintained within a single entity

· Binary Relationship

– Two entities are associated

· Ternary Relationship

– Three entities are associated

relationship degree

Cardinality of Relationship

• One – to – One

– Each entity in the relationship will have exactly one related entity

• One – to – Many

– An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity

• Many – to – Many

– Entities on both sides of the relationship can have many related entities on the other side

cardinalities

Notation

Notation

Data Flow Diagrams (DFD Quiz)

• A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps

• A set of DFDs provides a logical model that shows what the system does, not how it does it

• The DFD is designed to show how a system is divided into smaller portions and to highlight the flow of data between those parts.

• With a data-flow diagram, users are able to visualize how the system will operate, what the system will accomplish, and how the system will be implemented.