CSC 355 Database Systems

School of Computing, DePaul University

Winter 2025

Lecture 02: ER and Relational Models of Data

 Review: SQL Developer

Setting Up a connection

Running a command
 DESCRIBE the structure of a table
 SELECT all data from a table
 Setting Up a Connection

To set up a new connection to acadoradbprd01:
 Connection Name: YOURNAME355
 Username: your campusconnect username
 Password: cdm####### (your 7-digit Student ID)
 Hostname: acadoradbprd01.dpu.depaul.edu
 Port: 1521
 SID: ACADPRD0
 Test, then Connect

Double-click to Open an existing connection

Disconnect (and commit) when you’re done!
 Browsing Database Tables

Left window shows current Tables, click on + to expand list

Right-click on Tables and choose Refresh to see changes
(can also Commit changes)

Click on a table to view it in the center window (may need
to Refresh view also)
 COLUMNS shows schema
 DATA shows contents
 Saving SQLDeveloper Output

Three ways:
 Click on Save icon to save contents of Script Output
window to a file
 Highlight and then copy and paste contents of
Script Output window to a file
 Take and save screenshot of SQLDeveloper display
 Today’s Topics

The Entity-Relationship Model

Relational Model
 ER Model - Example

Rectangles are Diamonds are

“entity set” relationships

Ovals are
attributes
 ER Model

High-level data model diagram that defines the
conceptual view of the database
 Describes data as a set of entities, attributes, and
relationships
 Graphical view of the DB design
 Model created based on business specifications or
narratives (from users or product owners)
 ER Model

Business specifications:
Example: Bookstores Sales
 We management more than one bookstore
 Some customers haven’t bought books
 Books are identified by a 10-digital ISBN code
 We offer more than 10k books
 Prices of books vary from $2 to $10,000
 We keep all sales for at least ten years
 ER Model – Key components

As mentioned before, the ER Model describes data
as a set of entities, attributes, and relationships.
The key components are:
 Entities
 Attributes
 Relationships
 ER Model – Key components

Entity: anything that can be described or have
additional information stored. An entity is something
that exists as itself.
Example:
 BOOKSTORE
 CUSTOMER (PERSON)
 BOOK
 ER Model – Key components

Attribute: Something that describes or qualifies an
entity (represented by rectangle with round corners or
sometimes ovals)
 ER Model – Key components

Relationships: describe the relation between
two or more entities (represented by diamonds)
Examples: offers, buys
 ER Model – Key components

Relationships continued:
 An arrow indicates a Movie is owned by at
most one studio (many-one relationship)
Studios owns Movies
 ER Model – Key components

Relationships continued:
 When both sides of a relationship has
arrows, that indicates a 1:1 relation
Studios owns Movies
 ER Model – Key components

Relationships continued:
 Arrow with a rounded head means that not only is there a
Many:One relationship but also the one entity (e.g., Studio)
must exist (referential integrity)

Studios owns Movies

ER Model – Key components
 Practice: Your Turn

Say we want to design a database for a car
dealership:
 What would be the entities?
 Relationships?

Which relationships would be Many:Many, One:One, and
Many:One?
 Attributes?
Into a Relational Model
 Data Models

Data model describes three things about stored
data:
 Structure of the data: How is the data organized?
 Operations on the data: What can be done with the
data?
 Constraints on the data: How are the data restricted?
Relational vs. Semi-structured
 Relational vs. Semi-structured

Relational Model:
 Structure: Two-dimensional tables with links
 Operations: Relational algebra/SQL
 Constraints: Data domains, uniqueness

Semi-structured Model:
 Structure: Nested XML elements
 Operations: Element traversal, searching
 Constraints: Data domains, nesting restrictions
 Relational Model

Data is stored in two-dimensional tables called relations, each one
having a name.

Each row is a tuple representing one instance of the entity the table
represents

Each column is an attribute, representing a property for which each
instance has a value

The set of values that an attribute can take is called domain.

Note a relation is a set of tuples not a list of tuples, i.e., the order of the
tuples does not matter and there is no required sequence.
Relational Model
Relation Example
 Relation Example

Name: BOOK

Attributes: ID, title, author, price

Domains: integer (9 digits), string (of length at most 100),
string (of length at most 50), number with 2 decimals

Tuples: { (100546987, Algebra, Baldor, 125.00),
(140324567, Databases, Ullman, 83.99),
(110234562, Math I, Einstein, 98.75) }
Relation Example
 Properties of Relations

Each relation has a unique name (in DB)

Each attribute has a unique name (in relation)

Each component of a tuple is a single value from its
attribute’s domain (or NULL)

The order of the tuples does not matter

The order of the attributes does not matter

No two tuples in a relation are identical
 Relation Schema vs. Instance

The schema of a relation consists of the name of the
relation followed by a slit of its attributes (domains may
be included also…)
 EMPLOYEE (ID, Name, Dept, Salary)…
 EMPLOYEE (ID:number, Name:string, Dept:string,
Salary:number)…?
 EMPLOYEE (ID:integer(3), Name:string(20), Dept:string(12),
Salary:number(5.2)) …?
 Relation Schema vs. Instance

An instance of a relation is a set of tuples, where each
tuple contains a value for each attribute (from the
associated domain), or perhaps NULL (indicating no
value)
 DBMS enforces these “domain constraints”

Instances are often presented as tables rather than as
sets, but the order of the rows in these tables is not
significant
Relation Schema vs. Instance
 Candidate Keys

A candidate key is a minimal set of attributes that can
be used to identify a tuple in the relation
 this set is unique
 no subset of the set has this property
e.g., STUDENT: username or email or studentId

This property must hold for all possible relation
instances for it to be a candidate key
 Primary Keys

One of the candidate keys can be chosen as the primary
key for the relation

A relation may have many candidate keys, but can have
only one primary key
 The primary key will be underlined in the schema
 A primary key must have a unique set of values in each tuple,
and may not contain any NULL values in any tuple (“entity
integrity”)
Primary & Foreign Keys
 Foreign Keys

We link two relations using a shared key that is the primary key in
one of the relations

In the other relation, this key is called a foreign key
 dotted underline in the schema, with an arrow to corresponding primary
key
 Every value of the foreign key must be the value of the corresponding
primary key in some tuple
 Thus, the foreign key associates each tuple with exactly one tuple in
the relation that it references
Primary & Foreign Keys
 Referential Integrity

Every foreign key value must appear as the value of the primary
key in some row of the relation it references (“referential
integrity”)

This restricts the changes that can be made:
 To add a row containing a foreign key, the value the foreign key must
appear among the values of the referenced primary key
 To remove a row containing a primary key, the value of the primary
key must not appear among the values of any referencing foreign key
Primary & Foreign Keys
Primary & Foreign Keys
Primary & Foreign Keys
 Constraints

All of these are maintained by the DBMS:
 Domain constraints: In every tuple, the value of each attribute must
come from its specified domain
 Key constraints: Each tuple must have a unique set of values in
each of its candidate keys
 Entity integrity: Each tuple must have a unique set of values in its
primary key, and not any NULLs
 Referential integrity: Every foreign key value must appear as a
value of the primary key in some tuple of the relation it references
 Database Schema vs. Instance

The schema of a relational database consists of:
 The schema of each relation in the DB

Name, list of attributes (and maybe domains)

Primary keys and foreign keys underlined
 An arrow from each foreign key to the primary key it
references
 Database Schema vs. Instance

An instance of a relational database consists of:
 An instance of each relation in the database, where each
relation instance satisfies all the required constraints:

domain constraints, key constraints, entity integrity, referential
integrity (and any user-defined constraints)

Note: only the changes allowed by the DBMS are

those that result in another valid instance