rdb1 ws0910 v2 2x3 PDF

Exercise 1.
• What is a Database (DB) ?

– Collection of related data
– Represents some aspects of the real world
Relational
– Data is logically coherent
Database Systems 1 – Is provided for…
• …an intended group of users and
Wolf-Tilo Balke
• …applications
Joachim Selke Christoph Lofi
Institut für Informationssysteme
Technische Universität Braunschweig
www.ifis.cs.tu-bs.de
Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 2
Exercise 1.2 Exercise 1.3

• What is a DBMS ? What do you use it for? 1. Are the following features provided by a FS,
– A collection of programs to maintain a database a DB or both ?
– Used for: – Simple and fast data access: FS, DB
• Definition of Data and Structure
– Controlled redundancy: DB
• Physical Construction
• Manipulation – Sophisticated enforcement of standards: DB
• Sharing/Protecting – Backup and recovery: DB
• Persistence/Recovery
• …
• Example scenarios?
– Selling tickets, managing a course of study, …
Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 4

1. What is redundancy?
• The same information is stored several times
Which users groups interact with a running DBMS?
• Stored information could be derived – Database administrators
from already existing data
– Database designers
2. What are the two main disadvantages of
– Application programmers
redundancy?
• Waste of storage space – DBMS designers and implementers
• Problems in consistently updating data – Tool developers
3. What is the advantage of redundancy? – Operators and maintenance personnel
• Speed up data access
• Use case: For each railroad station and train,
– End users (naïve, sophisticated, casual)
precompute the list of all reasonable connecting trains!
(This information will be accessed very often but changes rarely)
Briefly define the following terms: Briefly define the following terms:
– Data Model:
– Declarative Querying • A data model is an abstract model that describes how data is
• Specify what you want, not how and from where to get it represented and accessed
• Three parts:
• No need to know position of files etc. – Integrity
• No need to know implementation details – Structure
– Manipulation
– View • Usually represented by three schemas (each schema respecting
• Create a different perspective of the data by the three model parts)
– Logical Schema
– Restricting the accessible information – Conceptual Schema
– Deriving additional, virtual information – Physical Schema
• This allows for customization of the accessible data for • Well defined structures support understanding/communication
specific user-groups • The use of a complete model makes sure the designed system
can be implemented
Data Modeling 1. Database Applications
• Introduction • Database applications consist of

• Basic ER Modeling – Database instances with their respective DBMS
– Chen notation – associated application programs interfacing with
– Alternative notations the users
App1
DBMS
• Example
App2
App3 DB1 DB2
Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 9 EN 3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 10
1. Database Applications 1. Universe of Discourse

• Planning and developing application programs • DB Design models a miniworld into a formal
traditionally is a software engineering problem representations
– Requirements Engineering – Restricted view on the real world with respect to the
– Conceptional Design problems that the current application should solve
– Application Design
–…
• Software engineers and data engineers cooperate Miniworld
Database
Operations
tightly in planning the need, use and flow of data
Information
Properties
Dependencies
– Data modeling Facts
Things
– Database design Relationships
EN 3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 11 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 12
1. Phases of DB Design 1. Phases of DB Design
Miniworld
• Requirements Analysis
Functional Requirements Requirements this lecture – Database designers interview prospective users and
Analysis
Data Requirements
stakeholders
Functional Conceptual
– Data requirements describe what kind of data is
Analysis Design needed
High Level Transaction
Specification
Conceptual Schema
– Functional requirements describe the operations
DBMS independent
DBMS dependent
Logical Design performed on the data
Application
Program Design Logical Schema
• Functional Analysis
Physical Design – Concentrates on describing high-level user operations
Transaction and transactions
Implementation Internal Schema
• Does also not contain implementation details
Application Programs • Should be matched versus conceptual model
EN 3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 13 EN 3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 14
1. Phases of DB Design 1. Phases of DB Design

• Conceptual Design
– Transforms data requirements to conceptual model
• While modeling the data, design phases have to
– Conceptual model describes data entities, relationships, constraints, be completed
etc. on high-level
• Does not contain any implementation details
• The result of one phases serves as input for the next phase
• Independent of used software and hardware • Often, automatic transition is possible with some additional
• Logical Design designer feedback
– Maps the conceptual data model to the logical data model used by
the DBMS
• e.g. relational model, hierarchical model, … conceptual
• Technology independent conceptual model is adapted to the used DBMS
logical
design
software design physical
• Physical Design ER-
design
diagram
– Creates internal structures needed to efficiently store/manage data tables,
UML,…
• Table spaces, indexes, access paths, … columns,… tablespaces,
• Depends on used hardware and DBMS software Indexes,…
EN 3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 15 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 16
2. ER Modeling 2. ER - Entities
• Traditional approach to Conceptual Modeling • Entities
– Entity-Relationship Models (ER-Models)
• Also known as Entity-Relationship Diagrams (ERD) – An entity represents a “thing” in the real world with
• Introduced in1976 by Peter Chen an independent existence
• Graphical representation • An entity has an own identity and represents just one thing
• Top-Down-Approach for modeling – Example: a car, a savings account, my neighbor‟s
– Entities and Attributes
house, the cat “Snowflake”, a product, …
– Relationships
– Constraints
• Some derivates became popular
– ER Crow‟s Foot Notation (Bachman Notation)
– ER Baker Notation
– Later: Unified Modeling Language (UML)
Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 17 EN 3.3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 18
2. ER - Attributes 2. ER – Entity Types
• Attributes • Entity Types are sets of entities sharing the

– A property of an entity, entity type or a relationship same characteristics or attributes
type. • Each entity within the set has its own values
– Example: name of an employee, color of a car, balance – Each entity type is described by its name and
of an account, location of a house,… attributes
– Attributes can be classified as being: • Each entity is an instance of an entity type
• simple or composite – Describes the so called schema or intension of
• single-valued or multi-valued similar entities
• stored or derived
• Example: name of a cat is simple, single-valued, and stored
EN 3.3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 19 EN 3.3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 20
2. ER – Entity Sets 2. ER Diagrams
• An Entity Set is the collection of all entities of a • ER diagrams represent entity types and
given entity type relationships among them, not single entities
– Entity sets often have the same name as the entity • Graphical Representation
type – Entity Type
• Cat may refer to the entity type as well as to the set of all
Cat entities (sometimes also plural for the set: Cats) • Rectangle labeled with the name of the entity
EntityType name
• Usually, name starts with capital letters
– Also called the extension of an entity type
(or instance) – Attributes
attribute 1
EntityType name • Oval labeled with the name of the attribute

• Usually, name starts with lower case letters
attribute n
2. ER Diagrams 2. ER – Composite Attributes
• Textual Representation • Simple Attribute:

– Entity Types – Attribute composed of a single component with an independent
existence
• Written as: EntityName (attribute1, attribute2, …)
– Example: name of a cat, salary of an employee,…
– Entity • Cat (name), Employee(salary),…
• Written as: (value of attribute1, value of attribute2, …) • Composite Attribute:
• Example – Attribute composed of multiple components, each with an
independent existence
– Entity Type Cat name
Cat • Graphically represented by connecting sub-attributes to main attribute
• Cat (name, color) color • Textually represented by grouping sub-attributes in ()
– Entity Set Cats – Example: address attribute of a company (is composed of street,
• (Fluffy, black-white) house number, ZIP, city, and country)
• (Snowflake, white) • Company (address(street, houseNo, ZIP, city)) street
houseNo
• (Captain Hook, red)
• … name Cat Company address ZIP
Simple Composite city

2. ER Multi-Valued Attributes 2. ER – Derived Attributes
• Single-Valued Attribute • Stored Attribute
– Attribute holding a single value for each occurrence of an – The attribute is directly stored in the database
entity type
– Example: name of a cat, registrationNo. of a student • Derived Attribute
• Multi-Valued Attributes (lists) – The attribute is (usually) not stored in the DB but derived
from an other, stored attribute
– Attribute holding (possibly) multiple values for each • In special cases, it might also be stored for read performance
occurrence of an entity type. reasons
• Graphically indicated by a double-bordered oval
• Textually represented by enclosing in {} – Indicated by dashed oval
– Example: telephoneNo. of a student – Example: Age can be derived from birth date, average
• Student ({phoneNo}) grade can be derived by aggregating all stored grades
birth date
name Cat Student phoneNo name Cat Student
age
Single Valued Multi-Valued Stored Derived
2. ER - Keys 2. ER - Keys
• Entities are only described by attribute values • Key attribute examples registration
Number
Student
– Two entities with identical values cannot be – Single key attribute name
distinguished (no OIDs, row IDs, etc.) • Student (registrationNumber, name)

• Entities (usually) must be distinguishable • (432451, Hans Müller)
– Composite key (multiple key attributes)
• Identification of entities with key attributes
• Car (licensePlate(districtId, letterId, numericId), brand, year)
– Value combination of key attributes is unique within • ((BS,CL,797),VW,1998) districtId
all possible extensions of the entity types
• Please note that each license
Plate letterId
– Key attributes are indicated by underlining the key attribute itself is

Car
attribute name not unique! brand

numericId
year
2. ER Modeling 2. ER - Domains
• Example Entity Type • Attributes cannot have arbitrary values: they are
– Book (isbn, {author(firstName, lastName)}, title, subtitle,
publisher(name,city, country), {revision(no, year)} ) restricted by the attribute value sets (domains)
– (0321204484, {(Ramez, Elmasri), (Shamkant, Navathe)}, – Zip Codes may be restricted to integer values
Fundamentals of Database Systems, (Pearson, Boston, US), between 0 and 99999
{(4,2004),(2, 1994)})
– Names may be restricted to character strings with
maximum length of 120
firstName
isbn
– Domains are not displayed in ER diagrams

author lastName
Book title
name
– Usually, popular data types are used to describe
publisher
domains in data modeling
no
• e.g. integer, float, string, ….
revision city
year country
2. ER - Domains 2. ER - Domains
• Commonly used data types • Using data types for modeling domains is actually
a crutch
Name
integer
Syntax
integer
description
32-Bit signed integer values between -231 and 231
– The original intention of domains was modeling all
double double 64-Bit floating point values of approximate
valid values for an attribute
precision • Colors: {Red, Blue, Green,Yellow}
numeric numeric(p, s) A number with p digit before the decimal and s
digitals after the decimal – Using data types is very coarse and more a
character char(x) A textual string of the exact length x convenient solution
varying character varchar(x) A textual string of the maximum length x • Colors: varchar(30) ???
date date Stores year, month, and day – To compensate for the lacking precision,
time time Stores hour, minute, and second values often restrictions are used
• Colors: varchar(30) restricted to {Red, Blue, Green,Yellow}
2. ER – NULL Values 2. ER – NULL Values
• Sometimes, an attribute value is not known or • What does it mean when you encounter a NULL-
an attribute does not apply for an entity value?
– This is denoted by the special value NULL – Attribute is not applicable
• e.g. attribute ”maiden name” when you don‟t have one
• So called NULL-value
– Value is not known
– Example: Attribute “universityDegree” of entity Heinz
Müller may be NULL, if he does not have a degree – Value will be filled in later
– Value is not important for the current entity
– NULL is usually always allowed for
any domain or data type unless – Value was just forgotten to set
explicitly excluded • Actually there are more than 30
possible interpretations…
EN 3.3 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 33 Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 34
ER – Relationships ER – Relationships
• Entities are not enough to model a miniworld • Similar to entities, ERDs do not model individual
– The power to model dependencies and relationships relationships, but relationship types
is needed • Relationship type
• In ER, there can be relationships between – Named set of all similar relationships with the same
attributes and relating to the same entity types
entities
• Diamond labeled with the name of the relationship type
– Each relationship instance has a degree name
• Usually, name starts with lower-case letters
• i.e. the number of entities is relates to
– A relationship instance may have attributes • Relationship set
– Set of all relationship instances of a certain
relationship type
ER – Relationships ER – Relationships
• Relationships relate entities within the entity • Example:

sets involved in the relationship type to each – There is an „ownership‟ relation between
other Relationship Type R Entity Type B cats and persons
A R B Person owns Cat
Relationship Instance R1
Entity A1 Relationship Set R Entity Set B – But more modeling detail is needed
• Does every person own a cat? Does every cat have an
A
A2
R
R1
B1 B owner?
A1
A3 B2
• Can a cat have multiple owners or a person own multiple
A4 R2 B3
cats?
A5
• Since when does a person own some cat?
A6 B4
R3 • Who owns whom?
ER – Relationship Cardinality ER – Relationship Cardinality
• Additionally, restrictions on the combinations of • Cardinality annotations

entities participating in an entity set are needed – One cardinality annotation per entity type / relationship end
• Minimum and maximum constrains
– Example: Relationship type “married to” possible cardinality
Person – Common Cardinality Expressions:

• (0, 1) : Zero to one instances are bound by the relationship (i.e.
married
to relationship end is optional)
• (1, 1) : Exactly one instance is bound
• Unless living in Utah, a restriction should be modeled that each • (0, *) : Any number of instances may be bound
person can only be married to single person at a time
• (1, *) : At least one instance is bound (at least one instance up to any
– i.e. each person entity may only appear once in the “married to” number)
relationship set
• No annotation is usually interpreted as (0, *)
• Cardinality annotations are used for this
• If only one symbol / number s is used, this is interpreted as (0, s)
• Relationship types referring to just one entity type are called – * = (0, *); 4 = (0, 4)
recursive • Sometimes, N or M are used instead of *
ER – Relationship Cardinality ER – Relationships
• Cardinalities express how often a specific entity • “To each entity of type B, one or two entities of
may appear within a relationship set type A are related”
(0, 1) (1, 2)
A r B
(0, 1) (1, 2)
A r B
– A specific entity of type A may appear up to once in

the relationship set, an entity of type B appears at
least once and at most twice A
A2
r
R1
B1 B
A1
• This means: Up to two entities of type A may relate to one A4
A3 B2
entity of type B. Some entities in A are not related to any in R2
B. All entities in B are related to at least one in A. A6 A5 R3

B3
R4
ER – Relationship Cardinality ER – Relationships
1 1
Person
• Example:
– “Each person can only be married to one other married
person“ 1 1
to
Person
married
to Person married
P2
to
P1 P3
– Each entity can only appear in one P4 R1
instance of the “married to” entity set P6 P5

R2
• Note: following this model a person
actually can marry him/herself
ER – Relationship Cardinality ER – Relationship Cardinality
• Example: • Example:
– “A cat has up to 4 owners, but at least one. A person – “A person may supervise any other number of
may own any number of cats. “ persons”
(0, *) (1, 4) • “Drake Mallard supervises Launchpad McQuack”
Person owns Cat
• “Drake Mallard supervises Gosaly Mallard”
• “Lisa owns Snowball”, “Lisa owns Snowball II”
(0, *) super
Person supervises
vises
(0, 1)
ER – Relationship Cardinality ER – Relationship Roles

• Cardinalities for binary relationship types can be • Often, it is beneficial to clarify the role of an
classified into common, more general cardinality entity within a relationship
types
– Example: Relationship “supervises”
– These cardinality types are also often found in other
modeling paradigms Person
(0, *) super
• 1:1 (One-To-One) – Each entity of the first type can only relate vises
(0, 1)
to exactly one entity of the other type
• 1:N (One-To-Many) – Each entity of the first type can relate to – What is meant? Who is the supervisor? Who is the
multiple entities of the other type supervised person?
• N:1 (Many-To-One) – Multiple entities of the first type can
relate to exactly one entity of the second type – Roles can be annotated on the relationship lines
• N:M (Many-To-Many) – No restrictions. Any number of (0, *) supervisor super
entities of first type may relate to any number of entities of Person
vises
second type. (0, 1) supervisee
ER – Relationship Degree ER – Relationship Attributes
• Relationship instances involve multiple entities • Similar to entities, relationship types may even
– The number of entities in each relationship instance is have attributes salary
called relationship degree works

Person Company
for
• Degree=2 : Binary Relation
Person owns Cat – For 1:1 relationships, the relationship attribute may be
migrated to any of the participating attributes
• Degree=3: Ternary Relation – For 1:N relationships, the attribute may be only
Supplier supplies Customer
migrated to the entity type on the N-side
– For N:M relationships, no migration is possible
Part
ER – Total Participation ER – Weak Entities
• To express that all entities of an entity type • Each entity needs to be identifiable by a set of
appear in a certain relationship set, the concept of key attributes
total participation can be used
– The entity type which is totally participating is • Entities existing independently of the context
indicated by a double line
are called strong entities
– Example: “Each driver‟s license must belong to a
– A person exists whether it is married or not
person”
• In contrast, there may be entities
Person owns
Drivers
License
without an unique key called
weak entities
ER – Weak Entities ER – Weak Entities

• Weak entities are identified by being related to – Weak entity types and identifying relationship types
strong entities are depicted by double-lined rectangles
– The strong entities “own” the weak entity – Example:
• The weak one cannot exist without the strong ones • “An online shopping order contains several order items”
– The relationships relating the strong to the weak are (0,*) is part (1,1)
orderNo Order OrderItem itemLine
called identifying relationships of
• The weak entity is always totally participating in that relationship • An order item can only exits within an order
– Weak entities have partial keys which are unique within • Each order item can be identified by the orderNo
the identifying relationship sets of their strong entities of it‟s owning order and its itemLine
• To be unique, the weak entity instance has to borrow the keys of
the respective strong entity instances
ER – Overview ER – Overview
• Entity Type Name • Total participation of E2 in R
• Weak Entity Type Name
E1 r E2
• Attribute name
• Cardinality
• Key Attribute name
– An instance of E1 may relate to multiple instances of
• Multi-valued Attribute name
name
E2 N 1
• Composite Attribute name
name
E1 r E2
• Derived Attribute name

• Specific cardinality with min and max
• Relationship Type name
– An instance of E1 may relate to multiple instances of
• Identifying Rel. Type name
E2 (0, N) (0,1)
E1 r E2
ER – Alternative Notations ER – Crow’s Foot Notation
• There is a plethora of alternative notations for • Crow’s foot notation was initially developed by
ER diagrams Gordon Everest
– Different styles for entities, relationships and – Derivate of ERD notation
attributes – Main Goal
– No standardization among them • Consolidate graphical representation
– Also, notations are often freely mixed • Provide a better and faster overview
• ER diagrams can look completely different depending on • Allow for easier layouting
the used tool / book – Widespread use in many current tools and
• In the following, we introduce the (somewhat documentations
popular) crow‟s feet notation
ER – Crow’s Foot Notation ER – Crow’s Foot Notation
• Entity Types • Relationship Types

– Entity Types are modeled with a named box – Relationship types are modeled by lines connecting
the entities
– Attribute names are written inside the box separated
by a line – Line is annotated with the name of the relationship
which is a verb
• Key attributes are marked with a leading asterisk
– Cardinalities are represented graphically
• Composite attributes are represented with indentation
• (0, 1) : Zero or one
firstName Book • (1, 1) : Exactly one
isbn * isbn
• (0, *) : Zero or more
author lastName author
firstName • (1, *) : one or more
Book title
lastName • ATTENTION: Cardinalities are written on the opposite
title
side of the relationship (in contrast to “classic ER”)
(0, *) (1, *)
Person owns Cat • Problem
– N-ary relationship types are not supported by
crow‟s foot notation, neither are relationship
Person
owns
Cat
attributes
• Workaround solution:
• What happens to n-ary relationships or – Intermediate entities must be used
relationship attributes? number
• N-ary relationships are broken down in a series of binary
relationship types anchoring on the intermediate entity
Supplier * supplies * Costumer A R C A Ra R RB C
* B Rc B
Part

number
Supplier * supplies * Customer • Originally, ER diagrams were intended to be used

*
on a conceptual level
Part – Model data in an abstract fashion independent of
implementation
• Crow‟s foot notation sacrifices some conceptual
Supplier provides Supplies
number
is used Customer expressiveness
– Model is closer to the logical model (i.e. the way the
contains data is later really stored in a system)
Part – This is not always desirable and may obfuscate the
intended semantics of the model
ER – Even more notations… ER – Even more notations…

• Barker’s notation • Black Diamond Notation
– Based on Crow‟s Feet Notation
– Developed by Richard Barker for Oracle‟s CASE – Cardinalities are represented differently
modeling books and tools in1986 • Cardinality annotation per relationship, not per relationship
– Cardinalities are represented differently end
1 1
• (0, 1) : Zero or one • 1:1
N 1
• (1, 1) : Exactly one • 1:N
• (0, N) : Zero or more M N
• (1, N) : one or more • N:M
• Cardinalities position similar to Crow‟s Foot notation and – Also, N-ary relationships possible
opposite to classic ER
– Different notation of subtypes 1
N
• See next lecture • ternary 1
2. ER – Mathematical Model 2. ER – Mathematical Model
• Mathematically, an attribute A of entity type E with • A relationship type R among n entity types
domain V is a function from E to the power set P(V) E1, E2, …, En defines a relationship set among
– A : E → P(V)
• The power set P(V) of V is the set of all subsets of V
instances of these entity types
– The value of an attribute of the entity e is denoted as – Each relationship instance ri within the relationship set
A(e) R associates n individual entities (e1, e2, …, en), and
– This definition covers each entity ej in ri is member of the entity type Ej,
• null values (empty set) 1≤j≤n
• single-valued attributes (restricted to singleton sets)
– Alternatively, the relationship type R can be seen as a
• multi-valued attributes (no restrictions)
subset of the Cartesian product of the entity types
– For a composite attribute A(A1, A2, …, An),V is defined as
• V = P(V1)  P(V2)  …  P(Vn)
• R ⊆ E1  E2  …,  En
An example An example
• We want to model a simple university database • How to start? What to do?
– In our database, we have students. They have a name, a – Find the basic entity types
registration number, and a course of study. – Find the attributes of entities
– The university offers lectures. Each lecture may be part of • Decide to which entity an attribute should be assigned
some course of study in a certain semester. Lectures may • Which attributes are key attributes?
have other lectures as prerequisites. They have a title, • Some attributes are better modeled as own entities, which ones?
provide a specific number of credits and have an unique ID – Define the relationship types
– Each year, some of these lectures are offered by a • Which role do entities play?
professor at a certain day at a fixed time in a specific • Do relationships require additional entity types?
room. Students may register for that lecture. • Are the relationships total? Identifying? Are weak entities
– Professors have a name and are member of a involved?
specific department. • What are the cardinalities of the relationship type?
• Which are our entity types?
Student Lecture Professor
– In our database, we have students. They have a name, a
registration number and a course of study.
• What attributes are there?
– The university offers lectures. Each lecture may be part of
some course of study in a certain semester. Lectures may – In our database, we have students. They have a name, a
have other lectures as prerequisites. They have a title, registration number and a course of study.
provide a specific number of credits and have unique ID – The university offers lectures. Each lecture may be part of
– Each year, some of these lectures are offered by a some course of study in a certain semester. Lectures may
professor at a certain day at a fixed time in a specific have other lectures as prerequisites. They have a title,
room. Students may attend that lecture. provide a specific number of credits and have unique ID
– Professors have a name and are member of a specific
– Professors have a name and are member of a specific
department.
department.
registration title credits registration title credits id
number number
id Lecture Professor
Student id Lecture Professor Student
prereq.
course of prerequisite part of

name name name department
study lecture curriculum
course of name department enrolls
study semester
curriculum Course of
name
semester Study name
• First try… • Second try

– This model is really crappy! – Professors use a surrogate key now
– “Course of study” does not seem to be an attribute • Key is automatically generated and has no meaning beside unique
• Used by student and lecture. Even worse, lecture refers to a course of identification
study in a specific curriculum semester. – Course of study is an entity type now
• Use additional entity type with relationships! • Which entity types are additionally related?
– “Prerequisite lecture” also is not a good attribute – “Each year, some lectures of the pool of all lectures are offered by a
• Prerequisite lectures are also lectures. Use a relationship instead! professor at a certain day at a fixed time in a specific room.
– “Professor” does not have key attributes Students may attend that lecture.”
day of room day of room
week week
time registration time semester id
registration semester id number
number
Lecture
attends teaches Student attends
instance
teaches Professor
Student instanciate Professor
instanciates name
name instantiates
name department
name department
title credits title credits
id Lecture id Lecture
enrolls enrolls
prereq. prereq.
part of • Not really part of
Course of curriculum
intuitive… Course of
curriculum
semester • Better?
semester Study
Study • Use an intermediate name • Add cardinalities
name
entity instead? • Add total and
identifying annotations
day of room
registration
number
time
week
semester id • The same example using Crow‟s Foot Notation
Student
N
attends
N
Lecture 1
teaches
N
Professor
– Note that the “part of” relationship had to use an
instance
1 1
intermediate entity
name
instantiates
name department
title credits
N
N Student Lecture Instance Professor
id attends teaches
enrolls Lecture +registrationNumber time +id
name dayOfWeek name
N N room department
prereq.
semester
N
part of • Better? enrolls
N curriculum instanciates
Course of semester • Add cardinalities
Study CourseOfStudy has PartOf has
Lecture
name +name curriculumSemester +id
title
credits
hasPrerequisite
An example
• Modeling is not that simple

• Many possible (and also correct) ways of
modeling the same miniworld
– Some are more elegant, some are less elegant
• Models alone are not enough, they need to be
documented
– What are the meanings of the attributes? The
meanings of the relationships?
Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 79

rdb1 ws0910 v2 2x3 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

rdb1 ws0910 v2 2x3 PDF

Uploaded by

Copyright:

Available Formats

Exercise 1.

• What is a Database (DB) ?

Exercise 1.2 Exercise 1.3

Exercise 1.4 Exercise 1.5

Data Modeling 1. Database Applications

• Introduction • Database applications consist of

App3 DB1 DB2

1. Database Applications 1. Universe of Discourse

1. Phases of DB Design 1. Phases of DB Design

• Attributes • Entity Types are sets of entities sharing the

2. ER – Entity Sets 2. ER Diagrams

EntityType name • Oval labeled with the name of the attribute

2. ER Diagrams 2. ER – Composite Attributes

• Textual Representation • Simple Attribute:

Simple Composite city

distinguished (no OIDs, row IDs, etc.) • Student (registrationNumber, name)

– Key attributes are indicated by underlining the key attribute itself is

attribute name not unique! brand

– Domains are not displayed in ER diagrams

2. ER – NULL Values 2. ER – NULL Values

• Relationships relate entities within the entity • Example:

ER – Relationship Cardinality ER – Relationship Cardinality

• Additionally, restrictions on the combinations of • Cardinality annotations

Person – Common Cardinality Expressions:

ER – Relationship Cardinality ER – Relationships

– A specific entity of type A may appear up to once in

entity of type B. Some entities in A are not related to any in R2

B. All entities in B are related to at least one in A. A6 A5 R3

– Each entity can only appear in one P4 R1

instance of the “married to” entity set P6 P5

ER – Relationship Cardinality ER – Relationship Cardinality

ER – Relationship Cardinality ER – Relationship Roles

called relationship degree works

ER – Total Participation ER – Weak Entities

ER – Weak Entities ER – Weak Entities

• Derived Attribute name

ER – Alternative Notations ER – Crow’s Foot Notation

ER – Crow’s Foot Notation ER – Crow’s Foot Notation

• Entity Types • Relationship Types

ER – Crow’s Foot Notation ER – Crow’s Foot Notation

Supplier * supplies * Customer • Originally, ER diagrams were intended to be used

ER – Even more notations… ER – Even more notations…

course of prerequisite part of

• First try… • Second try

part of • Not really part of

• Modeling is not that simple

Relational Database Systems 1 – Wolf-Tilo Balke – Institut für Informationssysteme – TU Braunschweig 79

You might also like