Intro File-Processing Systems limitations: lack of: integrity, standards, flexibility/maintainability The above stems from two main

problems: lack of data integration, lack of program-data independence Definitions External schema - different user views or subschemas which describe portions of the database of interest o Views - information of interest to a particular user group (e.g. a view of the myUH db shows class name, dates, teacher and rm #) Internal schema - describes the physical structure of the stored data (technology dependent) Data independence - means the view and the physical data are not dependent o Physical data indep - e.g. the DBA can move info to different tables without the user ever noticing a difference o Logical data indep - e.g. one user view doesnt affect another user view DBMS - database mgmt system, software that facilitates the manipulation of a database Database system - self-describing collection of interrelated data; includes data and metadata Distributed database (DDB) - multiple logically interrelated databases that may be geographically dispersed Distributed database mgmt system (DDBMS) - used to manage DDBs (user is not aware of data's geo location) Data warehouse - repository for data so it can be used by decision makers Data definition language (DDL) - Used for creating db structures like tables and views; typically SQL Data control languages (DCL) - handle administrative tasks like backups and security, typically SQL Data manipulation languages (DML) - facilitate modification of actual data; typically SQL Data dictionary - stores information about data (metadata) such as relationships, authorizations and usage Data repository - metadata about data models and application program interfaces Data model - used to represent real world phenomena, the blueprint for db design Universe of interest - myUH has info about students, classes, teachers, financial aid, etc. 'Types of insects' is probably outside myUH's universe of interest Requirements specification - interview users and review business documents to understand rules and objectives Business rules - organized set of restrictions describing the organization's activities Semantic modeling - the first step in db design, rules set forth by the business Conceptual modeling - the second step in db design, refers only to data specs, not business processes Data types - numeric, alphabetic, alphanumeric Derived attribute - e.g. instead of storing birthday, it is calculated by subtracting DOB from today's date Integrity constraints - rules that govern the behavior of data at all times in a db o Domain constraint - ensures the value is valid, e.g. 'StudentID' can only store numbers, not letters o Uniqueness/key constraint - requires instances of an entity to be unique when compared to other instances Key attribute - one or more attributes that make an instance unique

Non-key attribute - e.g. Since many students have a 'garage pass'

it does not help you identify a specific student instance

Attributes - underline the primary key/unique attribute. Use a

darkened circle for mandatory attributes, outlined circles for optional attributes, double circle for multivalued attributes Cardinality - the maximum amount of participants in a relationship. e.g. look for wording like a teacher may have up to 55 students. This is max in (min:max) notation. Participation constraint the minimum participants in a relationship. Look for may (0 or optional) or must (1 or as many as are specified). This is min in (min:max) notation. Domain constraint - indicates what type of values is acceptable, such as only dates or only numeric. Also indicates the amount of characters that are accepted [A,4] means alphanumeric and 4 characters. Deletion constraint: o cascade -> if you delete a parent all the children get deleted, C near child; o restrict -> don't allow you to delete parent if children exist, R near parent; o set default -> change a child's parent to some other parent to allow delete, D near child; o set null -> delete parent and allow child to have no parent, N near child Comparisons Entity type vs. instance - Student is an entity type. A specific student, like Joe Stood, is an instance. Instance is sometimes referred to simply as an entity Base(strong) vs. weak - Base entities are those that have independent, unique instances. Weak entities depend on their parent entity for uniqueness. Parent vs. child - look at the participation. A child must have a parent but a parent may not have a child ERD: Presentation vs. coarse vs. fine - presentation is the most basic and fine is the most detailed Diagraming 1. Identify the 'business rules' within the provided information/paragraph. Treat this is a checklist and cross items off when complete. Look for: a. Entity types b. Unique and non-unique attributes for each entity type c. Relationships between two or more entity types d. Participation between entity types, may means optional participation, must means full participation e. Cardinality between relationship types means f. Specific wording like: 1. May, must, might, may or may not, plural nouns vs. singular nouns (words that end in s vs words that begin with a or an) 2. Draw the diagram 3. Write a bulleted list of 'business rules' that were unable to be expressed in the diagram. This might include specific min/max values, domain constraints, relationship arcs, etc.

NOTE: These diagrams do not have primary key underlined because its too difficult to do in DiaPortable Presentation Layer ER Diagram

Fine Granular ERD 1. Follow all the steps in the previous diagram. e.g. (min:max), deletion constraints, etc. 2. Add domain constraints. e.g. [X,9] for 9 alphanumeric characters 3. Separate M:N relationships using a weak entity in the middle. 4. Break multi-valued attributes into weak entities.

Above is a Coarse Granular ERD. Below is what results after you convert it to a Fine Granular ERD

1. List all entities inside a square, use a noun 2. Write the relationship between the entities, use a verb

a) Draw a vertical line if biz rule says participation is a must or

draw an open circle if biz rule says may. Dont forget look across.

b) Write a 1, n, or m to indicate the maximum (cardinality) 3. List all attributes for each entity, underline the unique attribute(s), use a double circle for multi-valued attributes, use an open circle for optional attributes. Use a dotted underline for the partial key in a weak attribute 4. Write any remaining Semantic Integrity Constrains which are the remaining biz rules that cant be described by a simple Presentation Layer ERD Coarse Granular ERD 1. Follow all the steps from the previous diagram but make the modifications listed in the next step 2. Convert your lines and circles from steps 2a and 2b to (min:max) notation. Circles become 0 in front of the colon. Vertical lines become 1 in front of the colon. 3. Add deletion constraints.