Introduction to database: this is al about relational Modeling, attribute, domains etc

1. Lecture 2 - Relational Model
1
Fall 2001 Database Systems 1
Relational Model
• In the relational data model
– a database is a set of tables (with additional constraints,
programs and interfaces)
– a schema is the description of tables in a database
– a relation or a table is a “set” of tuples
– a tuple or a record is a mapping from a set of attributes to their
values
– an attribute is a slot for recording data, it has a name and a
domain of applicable values
– the schema of a table contains the table’s name and the
attributes and the domain of the attributes
Fall 2001 Database Systems 2
Example Database - Auction
• OWNERS - people who sell items
– Oid unique identifier given to them
– Name their name
– Email their e-mail address
• ITEMS - the items sold by “owners”
– Iid unique identifier of an item being sold
– Oid the owner of the item
– Name description of the item
– Location location of the item
• BUYERS - registered buyers allowed to bid on items
– Buyid buyer identifier
– Name buyer’s name
– Email buyer’s e-mail address

2. Lecture 2 - Relational Model
2
Fall 2001 Database Systems 3
Example Database - Auction
• BIDS - people place bids on a specific item of a
specific owner
– Bid unique identifier of a bid
– Date the date it was put online
– Iid which item
– Oid who owns the item
– Buyid who placed the bid
– Amount how much is the buyer bidding
• Additional logic:
– BIDS and ITEMS contain all the “unsold” items.
As soon as an item is sold, it is deleted from
bids and items. The loosing bidders are notified
that they lost the item.
Fall 2001 Database Systems 4
¢¡¤£¦¥¨§¨© £ ¥ !
#%$ (') 021 Smith@aol.com
#¦3 4657198A@ Johns@geocities.com
#B C9DE5GF8 Brown@netmail.com
#IH PQDERTS Gray@microsoft.com
UVXW(Y`¨a U9bTcde f¢gihqp Y¨hqg!d r
sut vXwExAy Gray@microsoft,com
€¨ ‚9ƒ„7…9†ˆ‡2‰ Robert432@aol.com
€9 ‘uƒi’“”‰ Johns@somewhere.co
m
€7• ‘¨–7‰Aƒ“ Jj@yahoo.com
€9— ˜Q™edA… Duke@jazz.com
fegih¨jk f!lm nlm oqpqir setTuGpevGltew
x9y z¦y {I|E}e~e€A
‚GƒT„ …
†i‡TˆA}”‡|
x9‰ z¦‰ Š6‹iƒeŒTeˆT…Geƒeˆ
Ž ‡G„ …i7}2‘“’
”i‡e€AˆA}E‡!|
x• z¦‰ Š6‹iƒeŒTeˆT…Geƒeˆ
Ž ‡G„ …i7}2‘“’
–qe—
˜u‡e2Œ
™7š ›¢œ !žeŸE A¡7¢E¢2¡ £6¤i¥ ¥¤G¦
™§ ›qš ¨¨¤e©e©ª7«
!ži¥ ¥¡i¬A¢T­ž®
¯ ¡7¤T¢”¢e¥¡
™i° ›¦± !žeŸE A¡7¢E¢2¡ ²ižT¦A¢”ž®
³9´9µQ¶ ³u·¸ µX¹iº2» ´!· ¸ ¼¦· ¸ ³9½T¾!´i¸ ¿ÀqÁ7½7ÂGº
ÃuÄ ÅuÆ Ç9È7É9Ê Ë!Æ Ì¦Æ ÃuÍ ÆÎʨÊ
ÃuÄ ÅuÍ Ç9È7É9Ê ËeÏ ÌÉ Ã¨Ð É9ʨÊ9ʨÊ
ÃuÄ Å¨É Ç9È7ÉuÆ Ë!Æ Ì¦Æ ÃuÍ Æ”Í!Ê
ÃuÄ Å!Ï Ñ9ÈiÆ ËiÒ ÌÉ Ã¨Ð ÍÏuÊ9ʨÊ
ÃuÄ Å¨Ð Ñ9ÈiÆ Ë!Æ Ì¦Æ ÃuÍ Æ”Í¨Æ
ÃuÄ ÅÒ Ñ9ÈiÍ ËeÏ ÌÉ Ã!Ï É¨Ð9Ê9ʨÊ
ÃuÄ Å9Ó Ñ9ÈiÍ Ë!Í Ì¦Í ÃuÆ ÍÐ9Ê
ÃuÄ ÅÇ Ñ9È7É Ë!Í Ì¦Í Ã¨É Í!ʨÊ

3. Lecture 2 - Relational Model
3
Fall 2001 Database Systems 5
Attributes and Domains
• Let D1 = the letter “O” followed by the set of all
integers
D2 = the set of all strings up to 30 characters
that contain only letters A-Z,a-z
D3 = the set of all strings that contain a single
@ symbol, and a combination of
Alphanumeric characters and “.”.
Then, owners relation has schema
Owners(OID:D1, Name:D2, Email:D3)
Fall 2001 Database Systems 6
Attributes - Domains
• All tuples in Owners come from
– D1 × D2 × D3
– An example tuple: OID:O1, Name: ’Smith’,
Email: ‘smith@aol.com’
– For any tuple: OID:v1, Name: v2, Email: v3
we have the property that v1 ∈ D1, v2 ∈ D2, v3 ∈ D3
• We usually abuse notation and assume an ordering
for the attribute/domain pairs, and write the relation
schema as:
Owners(OID, Name, Email)
and a tuple as:
O1,’Smith’,’smith@aol.com ∈ Owners

4. Lecture 2 - Relational Model
4
Fall 2001 Database Systems 7
More on domains
• A domain is a type in the programming language sense
• Domain values is a set of acceptable values for a
variable of a given type.
– Zipcode: zipcodeDomain = {11111, … ,99999},
– Grants: availableGrants = {50,000, … ,1,000,000}
– Simple/Composite domains
• Address = Street name+street number+city+province+ postal code
• Domain compatibility
– Binary operations (e.g., comparison to one another, addition, etc)
can be performed on them.
• Full support for domains is not provided in many current
relational DBMSs
Fall 2001 Database Systems 8
Relation Instances
• A relation/table instance is a set of tuples with a
specific schema (attribute/domain pairs)
List form:
OWNERS(OID,Name,Email) = { O1, Smith, smith@aol.com,
O2, Johns, johns@geocities.com, O3, Brown,
Brown@netmail.com, O4, Gray, Gray@microsoft.com }
Tabular form: Ô Õ¤Ö¦×uب٠ÔÚ Û ÖÜiÝIÞ ×¨ÝqÜ!Ú ß
à%á âäã¦åæAç Smith@aol.com
à¦è é6êeç9ëTì Johns@geocities.com
àí î!ïEêeðië Brown@netmail.com
àIñ òQïEóAô Gray@microsoft.com

5. Lecture 2 - Relational Model
5
Fall 2001 Database Systems 9
Relational Model
Based on finite set theory:
• First Normal Form Rule: all attributes take simple
values - no set values are allowed.
• Rows are accessed only by their content. The order of
tuples does not have any meaning.
• The order of columns does not have any specific
meaning either.
• No two tuples can have the same values for all the
attributes, i.e. relations are sets.
• Commercial systems allow duplicates (so bag
semantics)
Fall 2001 Database Systems 10
Keys
• A superkey is a set of attributes that help uniquely
identify a specific tuple
– if no two owners may have the same Oid, then Oid
is a superkey
– if no two owners may have the same email
address, then Email is a superkey
• How about:
– Oid + Name (together) for Owners?
– Oid + Name (together) for ITEMS?
– Iid + Oid (together) for ITEMS?

6. Lecture 2 - Relational Model
6
Fall 2001 Database Systems 11
Keys
• Given relation T, we use t[A1,…,Ak] to denote tuples with only
attributes A1,…,Ak
– for example, if t = O1, Smith, smith@aol.com then
t[oid,name] = O1, Smith
• Given a relation T with attributes {A1,…,Ak}, a key is a set of
attributes {B1,…,Bm} ⊆ {A1,…,Ak} such that
– if u and v are distinct tuples in relation T, then u[B1,…,Bm] and
v[B1,…,Bm] are necessarily different from each other by user
design!
– no proper subset of {B1,…,Bm} has this property
• Every table must have a unique primary key
– Primary key is a key designated by the user and managed by
the system
Fall 2001 Database Systems 12
Null values
• Attributes may be allowed to have null values because
– a value does not exist for a tuple
– a value exists, but it is not known
– it is not known whether a value exists or not
• Integrity rule: No column in a primary key can have null
values