Exam 2 Flashcards
Will the Database Application Develop Methodology work for general application development?
No
Database Application Development Methodology - Assumptions that must hold
- Business processes are well-designed
- Documents (input to our output from apps on the db) are known
- Tasks (the processing of those documents) are known
- System boundary is known
- One database schema unifying all views can be designed
Troubles with creating one database schema to unify views?
Can be difficult because: Interests, goals, power, politics
Question: is that a problem with…
Problems with methodology?
Problems with Organization?
Answer: Organization.
Because Oraganization = an entity created to pursue a shared set of goals
Typical waterfall software development steps?
- Business Process design
- Analysis
- Specification
- Design
- Implementation
- Testing
- Operation
- Maintenance
Software dev steps that are unique to database methodology?
<those>bold></those>
- Business Process design
- Analysis
- Specification
- Design
- Implementation
- Testing
- Operation
- Maintenance
In database application method, which is first?
Data is First
In contrast, other software dev, process often first
What are the steps of databse application development?
Information Flow Diagram (IFD) shapes
- Elipses = Tasks
- Rectangles = documents (input and output screens)
- Arrows = information flow (NOT CONTROL FLOW)
- Broken line = system boundary
Never connect 2 tasks
Never connect 2 documents
What goes into the database?
What comes out of the database?
- Everything in the database must come from somewhere
- Everything on the input documents must go somewhere
- Everything in the database must be used for something
- Everythingo n the output documents must come from somewhere
Lecture 17 - Lesson 3
Constraints - how to include them?
There are constraints from the data format.
There are constraints from the EER diagram.
Any other constraints are those that have to be coded into the program.
Data formats - How to get?
Beg, borrow and steal from existing sources.
Rules for Task Decomposition
- Lookup very different vs. insert, delete and update (why? because different “locks” for lookups)
- If task has many different of these, should likely be decomposed
- How many schema constructs are involved (requires many locks)
- Would want to decompose task when many schemas
- Are enabling conditions consistent across tasks?
- (easier to run now, when there are resources, so run what you can)
- Are frequencies consistent across tasks?
- (if some have high and some have low frequencies, split them)
- Reason is because you might want to index high frequency things
- Is consistency essential?
- (Depends on task, money transfer yes)
- (ACID transaction properties?)
- Is mother task control needed or not?
- Sometimes you do, others you don’t
Web-based apps features
- Traditionally, almost stateless
- Must have some state, like user email
- May need some click stream history
- Advent of things like AJAX allow more state which allows web-based apps to act more like traditional apps
Traditional Apps (as opposed to web-based)
- Much easier to manage local state separate from the DB
- Lots of changes can be collected before submitting them to the DB
- Means you don’t need a round trip to the DB everytime a minor thing is changed
- Supports better control of ACID transactions execution
*
Formatting for abstract code
BoldUnderline: Task definition
Bold: Task call
Italics: Button names
Relational Model Terms
Row = Tuple
Column header = attribute
Table = relation
Data type = domain
Domain (definition)
Set of atomic values (i.e. indivisible)
Often specified by a data type
Domain Components
Comprise a name, datatype and format
Logical definitions = e.g. “set of valid 10-digit us phone numbers”
Datatype or format = (ddd) ddd-dddd where d = decimal
Unit types (optional) = kg
Relational Scheme
Name = relation name
Attributes are name of a domain in the schema (i.e. column)
Degree = number o attributes
Dom(attribute) = domain of the attribute
Relation
Set of rows
Each row has n-tuples
n = degree and number of attributes
Schema = intension
Actual rows = extension (i.e. state)
Domains can be same in attributes?
Yes (just data type).
But attributes play different *roles* in the relation
Difference between relation (mathematically defined) and the table or flat file (actual content)
- Order of tuples does not matter in relation, but exists in a table or flat file
- (therefore tables with different orders are considered identicle)
- Driven because relation = set of n-tuples
- Sets don’t have order in math
- Technically, n-tuple described as ordered list from math, but in reality, order of attributes shouldn’t matter
- Can re-define a tuple as a set to make it mathematically not care about order
- Makes two differently orderd tuples identicle
- Requires “dictionary” format (name:value) which is called *self-describing data*
-
Are tuple valus mult-valued or atomic?
Must be atomic
Called flat relational model
Assumption was a lot of relational theory
Assumption called first normal form
Null value types
Value unknown (i.e. not sure if exists)
Value not available (i.e. know it exists, but don’t have it)
Attribute does not apply (value undefined)
Interpretation of a relation
Can be assertion that an entity or relationship has attributes.
- Each tuple then is a fact
- Can be facts about entities or relationships (hard to tell each)
Alternatively, can be a predicate. The values are values that satisfy the predicate. Useful for logical programming.
What is the closed world assumption?
Only true facts of the universe are those present in a extension (state).
Any other combincation would make a predicate false.
Useful for relational calculus.
Types of constraints
- Implicit constraints or inherent model-based constraints = Those inherent in the data model
- Schema-based constraints or explicit constraints = Those that can be expressed direclty in the schema (typically specified in the DDL)
- Application-based or semantic or business rules = Constraints that cannot be explicity in the schema or data model and must be enforced in the application
Types of schema- based constraints
- Domain constraints
- Key constraints
- Constraints on NULL
- Entity integrity
- Referential integrity
Domain Constraint
Specifies each attribute is atomic and of a specific domain
Domain could be a standard type or could be specified as a sub-set or even enumerated as explicit, possible values
Definition of relation
A set of tuples
Key constraint
That any given tuple is has a unique set of values.
This follows from fact that a relation is a set of tuples (and sets don’t have duplicates)
Superkey of a relational scheme
The subset of attributes in a tuple that would establish the uniqueness constraint
Every relation has one default superkey: the set of all its attributes