9-1 Introduction to Relational Database concepts

- The conceptual data model will be transformed into a relational database design
-  Entities, attributes, relationships and UID will be transferred into objects in a
relational database
- An entity is not a table, and an attribute is not a column

1. Relational Database Illustrated

- Relational Database = database that is seen by the user as a collection of two-
dimensional tables, each containing rows and column
- Relational Database = collections of objects or relations, set of operators to act
on those relations and data integrity for accuracy and consistency

2. Language to Access Data

- SQL = Structured Query Language – allows to access data in a relational
database in an efficient way

3. SQL Query Illustrated + Specific SQL Query

- SELECT statement
- SQL allows you to access the whole table or just parts of the table, depending on
what comes after SELECT and what is specified in the WHERE clause

4. Primary Key
- PK = a column or set of column that uniquely identifies each row in a table
- PK= a constraint which ensures that the column contains no null values and
unique identifies each row of the table
- It is possible to create a table without a PK, but it is not recommended, each
table should have a PK and a PK must be unique

5. Primary Key Candidates

- A table can have more than one column, or combinations of columns, that could
serve as the table’s PK
- “candidate key” =a column, or combinations of columns that could serves as the
table’s PK
- When you select one candidate key to be the PK for the table, the other
candidates become alternate keys (or unique keys)
- Unique key= an integrity constraint that requires every value in a column or set
of columns to be unique

6. Foreign Key
- FK = a column or combinations of columns, in one table that contains values that
match the PK value in another table
- FK= a column or set of column that refers to a PK in the same table or in another
table
- If a PK is composed of one or more foreign key, the FK value cannot be null

7. Column Integrity
- A column must contain only values that are consistent with the defined data
format of the column
- Row= an entry in a table, consisting of values for each appropriate column
- Column= an implementation of an attribute or relationship in a table

8. Summary of Data- Integrity Rules

- Data- Integrity Rules = constraints – define the relationally correct state for a
database
- Ensure that users can perform only those operations that leave the database in a
correct, consistent state

9-2 Basic Mapping: The Transformation Process

- Conceptual model vs. physical model
- Transform an entity into a table diagram
- When we create a conceptual model, we are focused on the business and its
rules
- When we create a database design, the focus will be on database issues of
storage, speed of transactions, security, etc.

1. Review of Relational Tables

- A table is a simple structure in which data is organized and stored
- Tables have columns and rows
- Each column is used to store specific type of value
- The value in the PK column distinguishes each individual row
- For a column in a table that is unique key, the system does not allows two rows
with the same unique key
- FK column refers to a column in another table

2. Transforming Conceptual to Physical

- The conceptual model (= ER diagram) is transformed into a physical model
- The physical implementation will be a relational database
- Transform = to change the elements of an ERD (entities, attributes, relationships)
into database elements (tables, attributes, foreign keys)

3. Terminology Mapping
- Map = to associate the elements of an ERD (entities, attributes, relationships)
with database elements (tables, attributes, foreign keys)
- An entity becomes a table
- An instance becomes a row
- An attribute becomes a column
- A primary unique identifiers cecomes a primary key
- A secondary unique identifier becomes a unique key
- A relationship is transformed into a foreign key column and a foreign key
constraint

- Analysis and design are phases of the system development life cycle
- Data modeling is done in the analysis phase

4. Table Diagram Notations

5. Naming Conventions for Table

- The table name is the plural of the entity name

- Column names : special characters and spaces are replaced with underscores
 6. Table Short Names
- Are not mandatory, simply useful
- A unique short name for every table is useful in the naming of FK column
- For entity names of more than one word:
o First character of the first word
o First character of the second word
o Last character of the last word
- For entity names of one word but more than one syllable:
o First character of the first syllable
o First character of the second syllable
o Last character of the last syllable
- For entity names of one syllable but more than one character:
o First character
o Second character
o Last character

7. Naming Restrictions with Oracle

- Table and columns name:
o Must start with a letter
o Can contain up to 30 alphanumeric characters
o Cannot contain spaces or special characters except ( $,# and _ )
o Table names must be unique within one user account in the oracle
database
o Colum names must be unique within a table
- “Reserved words” = word with a special meaning in the Oracle database and in
the SQL programming language : table, number, sequence, order values, level,
type

9-3 Relationship Mapping

- Transform relationships in an arc
- Relationships are mapped between PK and FK to allow one table to reference
another

1. Rules for Relationship

- A relationship can create one or more FK columns in the table on the many side
of the relationship
- The FK column may be either mandatory or optional, depending on the needs of
the business
 2. Rules for Relationships Illustrated

3. Mapping of the Mandatory Relationship at the one side

- Relationships that are mandatory on the one side, or mandatory on both sides,
are mapped exactly the same way as a relationship that is optional on the one
side
- Conceptual model capture optionality at both ends of the relationship
- The physical model is limited in that a foreign key constraint can enforce a
mandatory relationship only at the many end.

4. Enforcing Optionality

5. Mapping of Nontransferable Relationship

- Nontransferable Relationship (in conceptual model) = the FK column in the
database table cannot be updated
- Nontransferable Relationship = information that cannot be updated
- The FK constraint by itself cannot enforce this in the database, but this can be
make =with additional programming

6. Enforcing Nontransferable Relationship

7. Mapping of Barred Relationships

- A barred Relationships is mapped to a FK column on the many side, just like ant
other 1:M Relationships
- The FK pays a double role because it is also part of the PF

-
 8. Cascade Barred Relationships
- = a series of relationships implying that the UID of each entity in the chain is
carried down to the entity on the next level
- The suggested convention is to never use more than two table prefixes

9. Mapping Many-To- Many Relationships

- A M:M relationships is resolved with an intersection entity, which maps to an
intersection table
- Intersection entity= the product of the resolution of a many to many relationship

-
 10. Mapping One-To- One Relationships
- When transforming a 1:1 relationship you create a foreign key and a unique key
- If the relationship is mandatory on one side, the FK is created in the
corresponding table

11. Optional One-To- One

- If the relationship is optional on both sides, you can choose which table gets the
FK

-
 12. Enforcing One-To- Many
- If the relationship is mandatory at both ends, you have the same limitation in the
database as 1:M relationship that is mandatory at the one end. You need to write
additional code to enforce it
- Mandatory 1:1 relationships are rare. In most cases will be modeled as a single
table, without a need for 1:1 Relationship
-
13. Mapping arcs
- The entity that has the arc will map to a table that contains FK from the tables on
then “one” end of the relationship
- Even if the relationships on the arc are mandatory on the many side, the resulting
FK have to be optional ( because one of them will always be blank)

- Arc represent exclusive relationships and additional code is needed to enforce

that only one of the FK has a value for every row in the table with a check
constraint in the database
- Ex: check (clm_id is not null and clm2_id is null)
- A check constraint is programming code that can be stored in the database. It
can enforce simple rules that apply to a single row in the table (such as
comparing values or ensuring that they are null or not null). This is the case with
the arc.
- In the case of a mandatory one end of a 1:M or 1:1 relationship, we have to
check that if a row is entered in one table (the master), a row must also be
entered in another table (the child, or detail).
- A check constraint cannot span two tables or different rows in the same table. It
cannot prevent insert, update, or delete operations. This is why additional
programming (instead of a check constraint) is necessary
 9-4 Subtype Mapping
- There are three ways to implement sybtypes in the database

1. Supertype Implementation: Single Table ( ingle table or one table

implementation)
- Produce a single table for the implementation of the supertype entity and its
subtypes
- Rules:
o Only one table is created, regardless of the number of subtypes
o Columns: the single table gets one column for each attribute of the
supertype, along with the original optionality of the attribute
o The table also gets a column for each attribute belonging to the subtype,
but the columns all become optional
o A mandatory column shoul be created to act as a discriminator column to
distinguish between the different subtypes of the entity
o The discrinimator column is usually called <table_short_name>_type
o Identifiers: UID transform into PK and UK
o Relationships at the supertype level transform as usual
o Relationships at the subtype level are implemented as optional FK column
o Integrity constraints > a check constraint is needed to ensure that for each
particular subtype, all column that come from mandatory attributes are not
null

- An other sybtype is recommended in the conceptual model to ensure that the

subtypes are exhaustive
- The single table implementation is common and flexible
2. Subtype Implementation: Two Tables
- Two-table implementation
- To create a table for each of the subtypes
- You can have more than two subtypes  you will have more than two tables
- Subtype = something an entity may be split into based on common attributes
and/or relationship
- Rules :
o One table per first-level sybtype
o Columns: each table gets one column for each attribute of the supertype
along with its original optionality
o Each table also gets one column for each attribute belonging to the
subtype along with its original optionality
o Identifiers
: the P UID at the supertype level creates a pk for each table; secondary
UIDs of the supertype become unique keys in each table
o Relationships> all table get a fk for a relationship at the supertype level
with the original optionality
o For relationships at the subtype levels the FK is implemented in the table it
is mapped to and original optionality is retained
o The original optionality of the attributes and relationships is carried over to
the columns and foreign keys, so there is no need for a check constraint
as there is in the one-table implementation.
o If there were a need to have unique values of the primary key (ID) across
both tables, then additional programming would be necessary.

- Subtype implementation may be appropriate when:

o Subtypes have very little in common/ there are few attributes as the
supertype level and several at the subtype level
 o Most of the relationship are at the subtype level
o Business rules and functionality are quite different between subtypes

3. Modeling the Supertype as an Arc

- Original ERD with the supertype and subtypes

4. Model an Arc Illustrated

5. Supertype and subtype (Arc) implementation

- This choice produces one table for every entity
- The supertype table has a foreign key for each subtype table
- These FK represent exclusive relationships
- FK are optional because only one of the can have value for each row in the table
- Rules :
o Tables > as many tables are created as there are subtypes as well as one
for the supertype
o Columns> each table gets a column for all attributes of the entity is based
on, with the original optionality
o Identifiers> the primary UID of the supertupe level creates a pk for each of
the tables; all other UId become unique keys in their corresponding tables
o Relationship: all tables get a FK for a relevant relationship at the entity
level with the original optionality
o Integrity constraints> two additional column are created in the table base
on the supertype; they are FK columns referring to the tables that
implement the subtypes; the columns are optional because the FK are in
an arc and are also unique keys
o An additional check constraint is needed to be implement the arc

- This implementation is rarely used, but could be appropriate when>

o Subtypes have very little in common and each table reper information that
cand be use independently