Oracle Academy -Week 1-

1. Oracle Academy -Week 1-

2. Entities and Instances • An entity is: • - “Something” of significance to the business about which data must be known • - A name for the things that you can list • - Usually a noun •  Examples: objects, events •  Entities have instances.

3. Attributes and Unique Identifiers • Like an entity, an attribute represents something of significance to the business. • An attribute is a specific piece of information that: • Describes an entity • Quantifies an entity • Qualifies an entity • Classifies an entity • Specifies an entity An attribute has a single value.

4. Attributes and Unique Identifiers • Attributes have values. An attribute value can be a number, a character string, a date, an image, a sound, etc. These are called "data types" or "formats." Every attribute has a data type. • Some attributes (such as age) have values that constantly change. These are called "volatile attributes." • Some attributes must have a value. These are mandatory attributes. For example: in most businesses that track personal information, name is required.   • Others attributes may have a value or be left null. These are optional attributes. For example: cell phone number is often not required, except in mobile or wireless applications. • A UID is an attribute or combination of attributes that distinguish one instance from another.

5. Entity relationships • Each relationship: • Represent something of significance to the business • Show how entities are mutually related • Always exists between two entities (or one entity twice) • Always has two sides • Is named at both ends • Has an optionality • Has a degree or cardinality Optionality = Must or may? Cardinality = How many?

6. ER Diagramming Conventions Drawing Conventions • Entities are represented by softboxes. • Entity names go in the softboxes. • Entity names are always singular and written with all capital letters. • Attributes are listed under the entity names. • Mandatory attributes are marked with “*.” • Optional attributes are marked with “°.” • Unique identifiers are marked with “#.” • Relationships are lines that connect entities. • These lines are either solid or dashed.   • These lines terminate in a “single toe” or a “crow’s foot” at the end of each entity.

7. Drawing Relationships and Speaking ERDish The components of ERDish: 1. EACH 2. Entity A 3. OPTIONALITY (must be/may be) 4. RELATIONSHIP NAME 5. CARDINALITY (one and only one/ one or more) 6. Entity B Since a relationship has two sides, we first read one side -- from left to right.

8. Matrix Diagram • It is useful to know more than one way of discovering relationships. The matrix diagram is a good way to make sure that we haven’t missed any relationships -- especially useful when you are dealing with a lot of entities.

9. Supertypes and Subtypes • Sometimes it makes sense to subdivide an entity into subtypes. This may be the case when a group of instances has special properties, such as attributes or relationships that exist only for that group, or when there is some functionality that applies only to the group. In this case, the entity is called a "supertype" and each group is called a subtype. A subtype: • inherits all attributes of the supertype • inherits all relationships of the supertype • usually has its own attributes or relationships • is drawn within the supertype • never exists alone • may have subtypes of its own • is also known as "subentity"

10. Supertypes and Subtypes • Always More Than One Subtype • When an ER model is complete, subtypes never stand alone. In other words, if an entity has a subtype, there should always be at least a second subtype. This makes sense. What use would there be for distinguishing between an entity and the single subtype? This idea leads to the two subtype rules: Exhaustive: • Every instance of the supertype is also an instance of one of the subtypes. Mutually Exclusive: • Every instance of the supertype is of one and only one subtype. You can nest subtypes. For ease of reading --  “readability” -- you would usually show subtypes with only two levels, but there is no rule that would stop you from going beyond two levels.

11. Documenting Business Rules • Two Types of Business Rules: Structural and Procedural • Structural business rules indicate the types of information to be stored and how the information elements interrelate. • Procedural rules are workflow or business process related.

12. Relationship Transferability • Optionality Can you have a TYPE that does not classify any SONG? Must every SONG have a TYPE? • Cardinality How many SONGs can be lumped into a TYPE? How many TYPEs can a SONG have? • Transferability Can a SONG be changed from one TYPE to another TYPE?

13. Relationship Types • One-to-Many (1:M) Relationships The various types of 1:M relationships are most common in an ER Model. You have seen several examples already. • Many-to-Many (M:M) Relationships The various types of M:M relationships are common, particularly in a first version of an ER model. In later stages of the modeling process, most M:M relationships, and possibly all, will disappear. • One-to-One (1:1) Relationships Usually you will find just a few of the various types of 1:1 relationships in every ER model. Mandatory at one end of the 1:1 relationship commonly occurs when roles are modeled. See the school model. 1:1 relationships (of all three variations) also occur when some of the entities represent various stages in a process. • Redundant Relationships A redundant relationship can be derived from another relationship in the model.

14. Resolving Many-to-Many Relationships • Resolution of a M:M Relationship A third entity is needed to resolve the resulting M:M relationship. This is called the "intersection" entity. • Barred Relationships The unique identifier (UID) of the intersection entity often comes from the originating relationships and is represented by the bars. In this case, the relationships from the originating entities to the intersection entity are called "barred" relationships.

15. Normalization and First Normal Form • First Normal Form (1NF) • First Normal Form requires that there be no multivalued attributes and no repeating groups. To check for 1NF, validate that each attribute has a single value for each instance of the entity.