Chapter 3 manufacturing, personnel organization in

Relational Data Model companies

Introduction  Language is simple; uses constructs like GET, GET
A specific DBMS has its own specific Data Definition Language, UNIQUE, GET NEXT, GET NEXT WITHIN PARENT etc.
but this type of language is too low level to describe the data DISADVANTAGES of Hierarchical Data Model:
requirements of an organization in a way that is readily  Navigational and procedural nature of processing
understandable by a variety of users.  Database is visualized as a linear arrangement of
We need a higher-level language. records
Such a higher-level is called data-model.  Little scope for "query optimization"
Data Model: a set of concepts to describe the structure of a 1. Network Model
database, and certain constraints that the database should  Allows record types to have more that one
obey. parent unlike hierarchical model
A data modelis a description of the way that data is stored in  A network data models sees records as set
a database. Data model helps to understand the relationship members
between entities and to create the most effective structure to  Each set has an owner and one or more
hold data. members
Data Model is a collection of tools or concepts for describing  Allow no many to many relationship between
 Data entities
 Data relationships  Like hierarchical model network model is a
 Data semantics collection of physically linked records.
 Data constraints  Allow member records to have more than one
The main purpose of Data Model is to represent the data in an owner
understandable way.
Categories of data models include: Job
Department
 Object-based
 Record-based
 Physical
Record-based Data Models
Consist of a number of fixed format records.
Each record type defines a fixed number of fields, Employee
Each field is typically of a fixed length.
Activity
 Hierarchical Data Model
 Network Data Model
 Relational Data Model
Hierarchical Model
 The simplest data model Time Card
 Record type is referred to as node or segment
ADVANTAGES of Network Data Model:
 The top node is the root node
 Network Model is able to model complex
 Nodes are arranged in a hierarchical structure
relationships and represents semantics of
as sort of upside-down tree
add/delete on the relationships.
 A parent node can have more than one child
 Can handle most situations for modeling using
node
record types and relationship types.
 A child node can only have one parent node
 Language is navigational; uses constructs like
 The relationship between parent and child is
FIND, FIND member, FIND owner, FIND NEXT within
one-to-many
set, GET etc. Programmers can do optimal
 Relation is established by creating physical link
navigation through the database.
between stored records (each is stored with a
DISADVANTAGES of Network Data Model:
predefined access path to other records)
 Navigational and procedural nature of processing
 To add new record type or relationship, the
 Database contains a complex array of pointers that
database must be redefined and then stored in
thread through a set of records.
a new form.
 Little scope for automated "query optimization”
2. Relational Data Model
Department  Developed by Dr. Edgar Frank Codd in 1970
(famous paper, 'A Relational Model for Large
Shared Data Banks')
 Terminologies originates from the branch of
mathematics called set theory and relation
 Can define more flexible and complex relationship
Employee Job  Viewed as a collection of tables called “Relations”
equivalent to collection of record types
 Relation: Two dimensional table
 Stores information or data in the form of tables
rows and columns
 A row of the table is called tuple equivalent to
Time Card Activity record
 A column of a table is called attribute equivalent
ADVANTAGES of Hierarchical Data Model:
to fields
 Hierarchical Model is simple to construct and
 Data value is the value of the Attribute
operate on
 Records are related by the data stored jointly in
 Corresponds to a number of natural hierarchically
the fields of records in two tables or files. The
organized domains - e.g., assemblies in
related tables contain information that creates the
relation
  The tables seem to be independent but are related Every relation has a schema, which describes the
some how. columns, or fields the relation itself corresponds to our
 No physical consideration of the storage is required familiar notion of a table:
by the user A relation is a collection of tuples, each of which
 Many tables are merged together to come up with contains values for a fixed number of attributes
a new virtual view of the relationship  Existence Dependency: the dependence of an entity on
Alternative the existence of one or more entities.
terminologies  Weak entity : an entity that can not exist without the
Relati Table File entity with which it has a relationship – it is indicated
on by a double rectangle
Tuple Row Record 2. The ATTRIBUTES - the items of information which
Attrib Colu Field characterize and describe these entities.
ute mn Attributes are pieces of information ABOUT entities.
 The rows represent records (collections of information The analysis must of course identify those which are
about separate items) actually relevant to the proposed application.
 The columns represent fields (particular attributes of a Attributes will give rise to recorded items of data in the
record) database
 Conducts searches by using data in specified columns At this level we need to know such things as:
of one table to find additional data in another table  Attribute name (be explanatory words or
 In conducting searches, a relational database matches phrases)
information from a field in one table with information in  The domain from which attribute values
a corresponding field of another table to produce a are taken (A DOMAIN is a set of values
third table that combines requested data from both from which attribute values may be taken.)
tables Each attribute has values taken from a
Properties of Relational Databases domain. For example, the domain of Name
 Each row of a table is uniquely identified by a is string and that for salary is real
PRIMARY KEY composed of one or more columns  Whether the attribute is part of the entity
 Each tuple in a relation must be unique identifier (attributes which just describe
 Group of columns, that uniquely identifies a row in an entity and those which help to identify it
a table is called a CANDIDATE KEY uniquely)
 ENTITY INTEGRITY RULE of the model states that  Whether it is permanent or time-varying
no component of the primary key may contain a (which attributes may change their values
NULL value. over time)
 A column or combination of columns that matches  Whether it is required or optional for the
the primary key of another table is called a entity (whose values will sometimes be
FOREIGN KEY. Used to cross-reference tables. unknown or irrelevant)
 The REFERENTIAL INTEGRITY RULE of the model Types of Attributes
states that, for every foreign key value in a table (1) Simple (atomic) Vs Composite attributes
there must be a corresponding primary key value - Simple : contains a single value (not divided into sub parts)
in another table in the database or it should be E.g. Age, gender
NULL. - Composite: Divided into sub parts (composed of other
 All tables are LOGICAL ENTITIES attributes)
 A table is either a BASE TABLES (Named Relations) E.g. Name, address
or VIEWS (Unnamed Relations) (2) Single-valued Vs multi-valued attributes
 Only Base Tables are physically stores  Single-valued : have only single value(the value may
 VIEWS are derived from BASE TABLES with SQL change but has only one value at one time)
instructions like: [SELECT ..FROM ..WHERE .. E.g. Name, Sex, Id. No. color_of_eyes
ORDER BY]  Multi-Valued: have more than one value
 Is the collection of tables E.g. Address, dependent-name
o Each entity in one table Person may have several college degrees
o Attributes are fields (columns) in table (3) Stored vs. Derived Attribute
 Order of rows and columns is immaterial  Stored : not possible to derive or
 Entries with repeating groups are said to be un- compute
normalized E.g. Name, Address
 Entries are single-valued  Derived: The value may be derived
 Each column (field or attribute) has a distinct name (computed) from the values of other
All values in a column represent the same attribute and have attributes.
the same data format E.g. Age (current year – year of
Building Blocks of the Relational Data Model birth)
The building blocks of the relational data model are: Length of employment
 Entities: real world physical or logical object (current date- start date)
 Attributes: properties used to describe each Entity or Profit (earning-cost)
real world object. G.P.A (grade point/credit
 Relationship: the association between Entities hours)
 Constraints: rules that should be obeyed while (4) Null Values
manipulating the data.  NULL applies to attributes which are
1. The ENTITIES (persons, places, things etc.) which the not applicable or which do not have
organization has to deal with. Relations can also describe values.
relationships  You may enter the value NA (meaning
The name given to an entity should always be a not applicable)
singular noun descriptive of each item to be stored in  Value of a key attribute can not be null.
it. E.g.: student NOT students. Default value - assumed value if no explicit value
 Entity versus Attributes o ONE-TO-ONE: one tuple is associated with
When designing the conceptual specification of the database, only one other tuple.
one should pay attention to the distinction between an Entity o E.g. Building – Location as a single
and an Attribute. building will be located in a single location
 Consider designing a database of employees for an and as a single location will only
organization: accommodate a single Building.
 Should address be an attribute of Employees or an o ONE-TO-MANY, one tuple can be associated
entity (connected to Employees by a relationship)? with many other tuples, but not the reverse.
 If we have several addresses per o E.g. Department-Student as one
employee, address must be an entity department can have multiple students.
(attributes cannot be set-valued/multi o MANY-TO-ONE, many tuples are associated
valued) with one tuple but not the reverse.
 If the structure (city, Woreda, Kebele, o E.g. Employee – Department: as many
etc) is important, e.g. want to retrieve employees belong to a single department.
employees in a given city, address o MANY-TO-MANY: one tuple is associated
must be modeled as an entity with many other tuples and from the other
(attribute values are atomic). side, with a different role name one tuple
The RELATIONSHIPS between entities which exist and will be associated with many tuples
must be taken into account when processing information. o E.g. Student – Courseas a student can
In any business processing one object may be associated take many courses and a single course can
with another object due to some event. Such kind of be attended by many students.
association is what we call a RELATIONSHIP between entity Relational Constraints/Integrity Rules
objects.  Relational Integrity
 One external event or process may affect  Domain Integrity: No value of the
several related entities. attribute should be beyond the allowable
 Related entities require setting of LINKS from limits
one part of the database to another.  Entity Integrity: In a base relation, no
 A relationship should be named by a word or attribute of a Primary Key can assume a
phrase which explains its function value of NULL
 Role names are different from the names of  Referential Integrity: If a Foreign Key
entities forming the relationship: one entity exists in a relation, either the Foreign
may take on many roles, the same role may be Key value must match a Candidate Key
played by different entities value in its home relation or the Foreign
 For each RELATIONSHIP, one can talk about the Key value must be NULL.
Number of Entities and the Number of Tuples  Enterprise Integrity: Additional rules
participating in the association. These two specified by the users or database
concepts are called DEGREE and administrators of a database are
CARDINALITY of a relationship respectively. incorporated
Degree of a Relationship
 An important point about a relationship is how
many entities participate in it. The number of
entities participating in a relationship is called
the DEGREE of the relationship.
Among the Degrees of relationship, the
following are the basic:
O UNARY/RECURSIVE
RELATIONSHIP:Tuples/records of a
Single entity are related withy each
other.
O BINARY
RELATIONSHIPS:Tuples/records of
two entities are associated in a
relationship
O TERNARY
RELATIONSHIP:Tuples/records of
three different entities are associated
o And a generalized one:
 N-NARY
RELATIONSHIP:Tuples from
arbitrary number of entity sets
are participating in a
relationship.
Cardinality of a Relationship
 Another important concept about relationship is the
number of instances/tuples that can be associated
with a single instance from one entity in a single
relationship. The number of instances participating or
associated with a single instance from an entity in a
relationship is called the CARDINALITY of the
relationship. The major cardinalities of a relationship
are: