1. CSIS 254 Oracle Database Design Day 3

2. Today’s Agenda Questions on homeworkQuestions on homework Review key concepts from last weekReview key concepts from last week Continue with Analysis stage of SDLCContinue with Analysis stage of SDLC –Entity Life History Diagrams –Data Flow Diagrams –Relational Databases

3. Seven System Development Stages (Review) The Software Development Life Cycle –Strategy / Scope –Analysis –Design –Programming –Testing –Go Live –Production & Maintenance

4. The Entity Relationship Model (ERM) Entities Entities are people, places, things, or events of interest to our system that can be divided into distinct classesEntities are people, places, things, or events of interest to our system that can be divided into distinct classes –An entity may describe physical things, or it may be conceptual Entity types (or sets) are collections of entities having similar propertiesEntity types (or sets) are collections of entities having similar properties Each occurrence of an entity type can also be called an instance or an objectEach occurrence of an entity type can also be called an instance or an object

5. The Entity Relationship Model (ERM) Attributes Attributes are relevant properties or characteristics that describe the entity instances in an entity setAttributes are relevant properties or characteristics that describe the entity instances in an entity set An attribute may be simple (atomic) or compositeAn attribute may be simple (atomic) or composite An attribute may also be single-valued or multi- valuedAn attribute may also be single-valued or multi- valued The values of an attribute in an entity instance may be restricted:The values of an attribute in an entity instance may be restricted: –mandatory, uniqueness, formatting, restricted domain...

6. The Entity Relationship Model (ERM) Keys An attribute (or combination of attributes) that uniquely identify an entity is called a key attributeAn attribute (or combination of attributes) that uniquely identify an entity is called a key attribute Key attributes are limited to the minimum set of attributes that can uniquely identify an entityKey attributes are limited to the minimum set of attributes that can uniquely identify an entity When an entity has more than one set of key attributes, they are called candidate keysWhen an entity has more than one set of key attributes, they are called candidate keys When a key does not contain any descriptive data about the entity,it is called a surrogate or natural key, or an identifierWhen a key does not contain any descriptive data about the entity,it is called a surrogate or natural key, or an identifier

7. The Entity Relationship Model (ERM) Derived Attributes A derived attribute is one that can be determined based upon the values of other attributes in the entity object or related entity objectsA derived attribute is one that can be determined based upon the values of other attributes in the entity object or related entity objects These might it be beneficial for us to include derived attributes in our physical database designThese might it be beneficial for us to include derived attributes in our physical database design –Performance –Redundancy –Security –Consistency (??) –Snapshots in time (as of)

8. Engineering Method Entity Diagrams Entity Name Attributes PALOMAR STUDENT Student ID Full Name First Name Middle Name Last Name Social Security Number Home Address Home Phone High Schools

9. Engineering Method Entity Diagrams A familiar Key exampleAttribute PUBLISHER Publisher Id Publisher Name Street Address CityState

10. The Entity Relationship Model (ERM) Weak Entity Types Entity types that do not have key attributes of their own are called weak entity typesEntity types that do not have key attributes of their own are called weak entity types Weak entities are always related to specific entities from another entity type -- the ownerWeak entities are always related to specific entities from another entity type -- the owner A weak entity must have a partial key or an identifier, which is a set of attributes that can be used to uniquely identify each instance from other instances belonging to the same ownerA weak entity must have a partial key or an identifier, which is a set of attributes that can be used to uniquely identify each instance from other instances belonging to the same owner

11. The Entity Relationship Model (ERM) Subtypes and Supertypes When different entity types share the same attributes, we can break out the common attributes into Supertypes, leaving the attributes that distinguish entities into SubtypesWhen different entity types share the same attributes, we can break out the common attributes into Supertypes, leaving the attributes that distinguish entities into Subtypes –There must be at least one attribute that distinguishes subtypes common to a supertype –An entity instance must belong to one and only one subtype

12. The Entity Relationship Model (ERM) Relationships A relationship is an association between two or more entitiesA relationship is an association between two or more entities Each relationship has an inverse relationshipEach relationship has an inverse relationship Participation or optionality refers to whether each entity instance must occur in the relationship (i.e., is it a mandatory relationship)Participation or optionality refers to whether each entity instance must occur in the relationship (i.e., is it a mandatory relationship) The degree of a relationship is the number of participating entity typesThe degree of a relationship is the number of participating entity types

13. Cardinality Cardinality is the maximum number of occurrences of each entity type that can occur in a relationshipCardinality is the maximum number of occurrences of each entity type that can occur in a relationship In binary relationships:In binary relationships: –A 1-to-1 relationship occurs when an entity of one type can occur in (at most) one relationship with an entity of the other type –A 1-to-many relationship occurs when an entity of one type can occur in (at most) one relationship with the other type, but entities or the second type can be related to any number of entities of the first type. –A many-to-many relationship occurs when no restrictions exist on the number of entities that can participate in a relationship

14. Relationships ER Diagrams In ERDs, entities that are related are connected by lines. (A 1-to-1 relationship is shown below.) SOCIALSECURITYNUMBERPALOMAR STUDENT ID

15. Relationships ER Diagrams Crow’s feet are used at the “many” end in 1-to-many relationships. COUNTRYRULER has had as Head of State

16. Relationships ER Diagrams Both sides of the line will have crow’s feet in a many- to-many relationship. CARMODELCOLORGROUP is available using

17. Relationships ER Diagrams A small circle is placed at the end of an optional participation, and a small perpendicular line placed at the end of a mandatory participation. WOMAN CHILDREN is biological mother of

18. Relationships ER Diagrams Subtype entities reference their supertypes using arrows, rather than lines. CARTRUCKBIKE LICENSEDVEHICLE

19. Relationships ER Diagrams All entity occurrences must fall into one of the subtypes CARTRUCKBIKE LICENSEDVEHICLE OTHER We add an “other” category to include RV’s, planes, motorcycles, etc.

20. ER Diagrams Relationships are (optionally) shown in diamonds connected to the associated entities meet in Super Bowl NATIONALLEAGUECHAMPAMERICANLEAGUECHAMP

21. Reflexive (Recursive) Relationships Occur when an entity has a relationship with another entity in the same entity setOccur when an entity has a relationship with another entity in the same entity set We might need to add business rules prohibiting certain recursive conditionsWe might need to add business rules prohibiting certain recursive conditions If participation is mandatory, then the relationship is circularIf participation is mandatory, then the relationship is circular If the relationship is hierarchical, then participation is optionalIf the relationship is hierarchical, then participation is optional

22. ER Diagrams Reflexive relationships are drawn with a single entity box PERSON is married to

23. Entity Life History Diagrams Entity-Relationship Diagrams describe the data in our system, but have no sense of order or sequenceEntity-Relationship Diagrams describe the data in our system, but have no sense of order or sequence Functional hierarchies or specifications describe processesFunctional hierarchies or specifications describe processes Entity Life History Diagrams (ELH) pull the two together for each entityEntity Life History Diagrams (ELH) pull the two together for each entity –They are also commonly known as State Transition Diagrams, as entities pass from creation to their final states (archived, deleted, distributed, etc.)

24. Generic Entity Life History Diagram Entity CreationTransactions Deletion or Archive Event 1 Event 3 Event A Event B Event 2 o o *

25. Entity Life History Notes The single entity being examined appears at the top of the diagramThe single entity being examined appears at the top of the diagram The rest of the diagram is comprised of events, which create, modify, or delete instances of the entityThe rest of the diagram is comprised of events, which create, modify, or delete instances of the entity A little ‘o’ in the upper-right corner of an event means “option” or selectionA little ‘o’ in the upper-right corner of an event means “option” or selection An asterisk ‘*’ in the upper-right corner means “iteration” or repetitionAn asterisk ‘*’ in the upper-right corner means “iteration” or repetition Basic flow of diagram is left-to-rightBasic flow of diagram is left-to-right

26. Entity Life History Example Payroll Check Job Cards TransferredProcessingArchive HoursSummarized CheckPrinted ApprovedRejected ReviewsMade o o * 2 years pass CalculationsPerformed

27. Data Flow Diagrams Are used to uncover as many data elements as possible in our data dictionaryAre used to uncover as many data elements as possible in our data dictionary Document the system from the data’s viewpoint (i.e., are data-centric)Document the system from the data’s viewpoint (i.e., are data-centric) Contain several entities on each diagram (unlike Entity Life History Diagrams)Contain several entities on each diagram (unlike Entity Life History Diagrams) Differentiate manual from automated processesDifferentiate manual from automated processes Show both external and internal processesShow both external and internal processes

28. Data Flow Diagram Example Purchase Requisition Fulfillment SUPPLIER issue P.O. D1 Inventory EMPLOYEE issue req. BUYER receive item D2 Accts Payable place req. P1 review & approve confirm P2 send to create order ship item P3 match to invoice updatestock

29. Data Flow Diagram Notes Rectangles represent entitiesRectangles represent entities Open-ended rectangles represent databases or data stores, and are labeled by a small box on their leftOpen-ended rectangles represent databases or data stores, and are labeled by a small box on their left Rounded rectangles represent processes, with the top part of the rectangle having a process numberRounded rectangles represent processes, with the top part of the rectangle having a process number Arrows represent data flows (either electronic or physical)Arrows represent data flows (either electronic or physical) Flow is generally from left-to-rightFlow is generally from left-to-right –Entities may appear more than once in the diagram to preserve the flow and directional nature

30. Data Flow Diagram Rules All processes must have at least one flow of data coming in and one going outAll processes must have at least one flow of data coming in and one going out All processes on the diagram should modify the incoming data and create new forms of outgoing dataAll processes on the diagram should modify the incoming data and create new forms of outgoing data Each data store and each external entity must be involved with at least one data flowEach data store and each external entity must be involved with at least one data flow

31. Relational Databases (Review) In relational databases, all data is stored in tables, which correspond roughly to entitiesIn relational databases, all data is stored in tables, which correspond roughly to entities Each table is two-dimensional, consisting of rows and columnsEach table is two-dimensional, consisting of rows and columns Each row in a table, called a t-uple, corresponds to an occurrence of the entityEach row in a table, called a t-uple, corresponds to an occurrence of the entity Columns in each table contain similar data across all rows in the tableColumns in each table contain similar data across all rows in the table

32. Relational Database Example The following table is an example of a relational table describing classes that students have taken at a mythical college used in the rest of this lesson Student Student Course Student Student Course Id Name Id Course Name Grade Term Teacher Id Name Id Course Name Grade Term Teacher 0194327 Joe Adams CSIS-840 VB Concepts C Spr-02 Wilkins 0194327 Joe Adams CSIS-840 VB Concepts C Spr-02 Wilkins 0194327 Joe Adams CSIS-824 Intro to C++ B Fal-02 Smythe 0194327 Joe Adams CSIS-824 Intro to C++ B Fal-02 Smythe 1850243 Joe Adams CSIS-740 Oracle Admin A Spr-03 Wallace 1850243 Joe Adams CSIS-740 Oracle Admin A Spr-03 Wallace 1850243 Jane Smith CSIS-941 Systems Des. B Fal-02 Evans 1850243 Jane Smith CSIS-941 Systems Des. B Fal-02 Evans 1850243 Jane Smith CSIS-840 VB Concepts B Spr-02 Wolkins 1850243 Jane Smith CSIS-840 VB Concepts B Spr-02 Wolkins 8502432 Ida Know CSIS-184 Networks A Sum-03 Farmer 8502432 Ida Know CSIS-184 Networks A Sum-03 Farmer 7402943 Eunice Eye CSIS-824 PowerPoint W Spr-02 Simpson 7402943 Eunice Eye CSIS-824 PowerPoint W Spr-02 Simpson

33. Relational Database Example Each row (or t-uple) in the table describes a Class taken by a Student in a term at our collegeEach row (or t-uple) in the table describes a Class taken by a Student in a term at our college The data in each column is consistent throughout the tableThe data in each column is consistent throughout the table However, there are three inconsistencies in the table itself. Can you find them?However, there are three inconsistencies in the table itself. Can you find them?

34. Primary Keys (Review) Each row in a table has a primary key, which is the column or set of columns identified to our DBMS that uniquely identifies it from every other row in the tableEach row in a table has a primary key, which is the column or set of columns identified to our DBMS that uniquely identifies it from every other row in the table No attribute value in a primary key can be NULLNo attribute value in a primary key can be NULL A table can have only one primary keyA table can have only one primary key If a primary key is not specified, Oracle supplies oneIf a primary key is not specified, Oracle supplies one What would be the primary key for our sample database?What would be the primary key for our sample database?

35. Foreign Keys (Review) An attribute (or group of attributes) in a table can also be a foreign key, meaning that it references the primary key (or at least unique attribute) to another tableAn attribute (or group of attributes) in a table can also be a foreign key, meaning that it references the primary key (or at least unique attribute) to another table An example would be a Customer Id attribute on an invoice header, which would reference the customer account information for that invoiceAn example would be a Customer Id attribute on an invoice header, which would reference the customer account information for that invoice