SWA exam

1. E/R modelling and mapping to relations (done)
2. Relational keys, foreign keys and XML keys (done)
3. Transactions (done)
4. SQL (done)
5. Using architectural qualities to describe systems (partly)
6. Using architectural styles to achieve qualities (partly)
7. The software architecture of the World Wide Web (done)
8. XML (done)
9. Aspects of secure systems (done)

2. Rewrite relation keys
6. Write some more

1. E/R modelling and mapping to relations

Slide 2-4


Purpose

• An easy way of showing ideas using diagrams
• Describing the mini-world
• Tool exists to convert into real implementations (relational databases)

Features

• Entities (squares)
• Entity set
• Attributes (circles)
• Relationships (diamonds)

Connections

• Different relationships
  • 1 : 1 (one at most)
  • 1 : n / n : 1
  • n : m
• Maximum participation (single line)
• Minimum participation (double line)
  • Has to be at least specified number of entities before it is in the entity set or relationship.
• Keys
• Weak entities (foreign keys)

Weak entities (foreign keys)

• Usually used when an entity can't be assigned a global unique ID
• Example: Soccer players should only have one number instead of number+team

Examples to draw

• 2 entities with attributes connected through a relationship
• m : n relationship
• Example entity with a key
• Foreign key (soccer team + player)

Relation diagrams
A database schema is a set of relation schemas

• Entities => relations
• Relations => relations (attributes
• Weak entities => relations

2. Relational keys, foreign keys and XML keys

• Keys provide the means by which tuples in a relational database may refer to another tuple
• They also ensure that an update will only affect one tuple

Relational keys

• A set of attributes is a key, if they functionaly determine the remaning keys
• A superkey is a set containing a key
• Can be identified by looking at the E/R diagram:
  • if a relation comes from an entity set, then the key of the entity set is the key for the relation.
    • If the relation comes from a relationship R between E1 and E2 which is
    • many-to-many, then we need the keys of E1 and E2.
    • many-to-one, then we only need the keys of E1.
    • one-to-one, then we can choose between the keys of E1 and E2.

Foreign keys

• Foreign keys make sure that referential integrity is maintained.
• Usually used when an entity can't be assigned a global unique ID
• Example: Soccer players should only have one number instead of number+team

XML keys

• IDs can be specified in a DTD as a unique identifier
• ID != Keys in XML since IDs don't scope
  • Person (1) and Student (1) isn't allowed
• XSD
  • Keys can be expressed using XPath expressions
  • Or by position in a document (e.g. number of bytes)
  • XML Key proposal
    • <db> <person>...</person> <person><age>18</age></person> </db>
    • <first element # child element # @attribute>
    • <1#2#@age> = 18

3. Transactions

Slide 5


What is a transaction

• A transaction is an atomic operation (all or none)
• If they are run at the same time
  • dirty reads
  • lost updates

ACID

• Atomic - Either whole process is done or none is
• Consistent - Database constraints are preserved
• Isolated - User don't see concurrent transactions
• Durable - Even if system crashes after a commit it is garuantied to exist

Example

• Person A & B read status
• Person A writes
• Person B writes

• Person A read status (START)
• Person A writes (END)
• Person B read status (START) (END)

SQL Support

• SQL supports transactions (often behind the scenes)
• Modeled using read/write operations
• BEGIN - Start transaction
• COMMIT - Commit and end transaction
• ROOLBACK - Abort and end transaction

Isolation levels
Each DBMS implements in its own way

• SERIALIZABLE
  • Only before and after other users transactions
• REPEATABLE READ
  • Same data item will have the same value during the transaction
• READ COMMITTED
  • Only committed data - but not same values (if changed by other commits)
• READ UNCOMMITED
  • Read data as it is currently disregarding if data is committed.

4. SQL

Slide 3-5


What is SQL

• SQL = Structured Query Language
• Used for quering and updating a database
• Industry standard based on
  • Relational algebra
  • Theory of transactions

Query
Basic query:

• SELECT attributes
• FROM list of tables
• WHERE condition holds

Operates on bags instead of sets

• Support for aggregation
  • SELECT AVG SUM COUNT MIN MAX (*)

Selection modifiers

• Intersect - Return elements that are in both sets
• Distinct - Only select one copy
• Union - Removes dublicates from all sets
• Except - Selects all fields except the ones specified

Updates

• Inserting
• Updating
• Deleting

5. Using architectural qualities to describe systems

Slide 6-7

• Quality attributes should adress the quality requirements
• Functionality is often the most important factor, and it relates to quality attributes without dictating it.
• Example, if one of the quality attributes is speed, then one could argue that its always possible to improve perfomance.
• Quality attributes are changed all the time during development.

Architectural qualities

• Result of the big picture (architecture and implementation)
• Example: Usability
  • Non architectural aspects
    • User interface, colors, fonts etc.
  • Architectural aspects
    • Undo, redo etc. functionality
    • Would depend on more components (editor, history log)
• Example: Performance
  • Non architectural aspects
    • Algorithms, environment
  • Architectural aspects
    • Amount of communication between components
    • Shared resources etc.

• In complex systems (a netbank) things like security or availability is hard to achive in isolation and at the same time.
• You would have to choose
• Example: Security vs reliability
• Example: Portability vs performance

Test areas

• Availability
• Modifiability
• Performance
• Security
• Testability
• Usability

Reference architectures

• General a good thing not to differ a lot from the above
• Makes it harder to find and train new staff
• Enables greater communication (able to plug into system)

6. Using architectural styles to achieve qualities

Slide 6+8

• Achivements of qualities is based on design decisions
• Design decisions => tactics
• Collection of tactics => architectural strategy

Availability tactics

• Fault detection
  • Ping / Echo
  • Heartbeat - send events through component chain
  • Exceptions
• Fault recovery
  • Put components into shadow operation untill they are stable
  • Checkpoints / rollback - create snapshots of consistent system
• Fault prevention
  • Use transactions like in SQL
  • Have monitor processes to clean up

Modifiability tactics

• Anticipate changes
• Generalise modules
• Maintain interfaces (prevent ripple effect)
• Use intermediary (like proxies and JDBC)
• Configuration files (at startup not at compile time)

Performance tactics

• Better algorithms and data structures
• Lower overhead from resources

Case study (J2EE)

• Industry platform that has out of the box support for
  • Availability
  • Balanced services
  • Buildability
  • Evolvability
  • Extensibility
  • Performance
  • Portability
  • Scalability
  • Security
  • Usability

7. The software architecture of the World Wide Web

Slide 6+9


Quality Goals of the WWW

• Remote access (using the Internet)
• No central server
• Can be used on multiple platforms (using libWWW)
• Programs can be extended (using libWWW)
• Data can easily be extended

E-Commerce Architectures

• Requirements
  • High performance (handle millions of requests - amazon)
  • High availability - 24/7 or 99.95%
  • Scalability - able to adabt to higher needs
  • Security
    • Users demand privacy of their data (from attackers)
    • Providers wants to be safe from attackers
• Structure
  • Accessed through a browser
  • Handled by BRA (Business Rules Applications) = transaction and application servers
  • Backed by Data service (DBMS)
  • N-tier architecture - logical partitioning of functionality
  • Above is a 3-tier architecture

Middle tier: Using Load Balancer or other parts to distribute 1-n (e.g. webserver to application servers)

• Browsers
• Protocols (HTTPS) for secure transfer
• Proxy servers
• Routers and firewalls (security and availbility)
• Load balancing (performance, scalability and availbility)
• Web servers (performance)
• Application servers (modifiability, performance and scalability)
• Databases (performance, scalability and availability)

8. XML

Slide 11-12


General problem

• Make information in from multiple sources look as a single source
• Solutions
  • Warehousing - static (generate a daily data set from sources)
  • Mediation - dynamic (query sources through wrappers)

XML

• XML is self-describing
• Schema information is part of the data
• Participants can supply a uniform data source
• Parts can be missing or have complex structure

Structure

• Always has one root element (thus is a tree)
• Attributes can be written as non-structured elements
• Can be viewed as a tree (show movie example)
• Document oriented example
• Recursive structure - elements can be nested

Document constrains

• Syntactical constrains (tags must match, attributes be unique etc.)
• Enable queries, since we know what, how many and where elements exists
• Integrity checks

• DTD - Document Type Definition
  • Specify what element tags are allowed
  • What attributes each element should have (requiered) and which are allowed
• XML Schema
  • Uses XML syntax - hence can be queried
  • Define constraints on document structure and datatypes
  • Large an complex standard (more complex than DTD)
  • Thus more flexible

Translating documents into a RDBMS

• Derive mapping from a DTD
• Use XSD to derive relation schema
• Specify by hand
• Store in a big table (nodes - id, parentid, type, value)
• Split into one table per element
• Combine into tables (e.g. where sub elements function attributes)
• Need to specify order if used in a textual way

Query XML documents

• One query language for all data sources

SOAP - Simple Object Access Protocol

• Exchanging structured and typed information
• Can be used for RPC (Remove Procedure Call)

Questions

• Why is XML not a datamodel like E/R models?

MovieList (movie*)
movie (title, year, actor*)
title(STRING)
year(STRING)
actor (STRING)

<xsd:element name='movie' type='movietype'>
  <xsd:complexType name='movietype'>
    <xsd:sequence>
      <xsd:element name='title' type='xsd:string' />
      <xsd:element name='year' type='xsd:integer' />
      <xsd:element name='actor' type='xsd:string' minOccurs='1' />
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

9. Aspects of secure systems

Slide 13-14


Definition from a Software Architecht

• Make sure that a system resists unauthorised access
• Provide services to legitimate users

Goals

• confidentiality - data are protected from unauthorised use
• assurance - identity of parties is ensured
• availability - system is available for legitimate use
• auditing - the system keeps logs of transactions

Secure vs. reliable

• Secure
  • Fewest points of failure
• Reliable
  • Most points of failure
  • Realised through redundancy (storage, processes, connections etc)

Secure architecture

• Only as secure as its weakest component
  • Identify points of failure
  • Strengthen weak components
• Don't leak confidential information (often happens in unexpected ways)
  • Error messages (Parse error in this code, query or file errors)
  • Response times (Help attacker probe for users and weak spots

Resisting attacks

• Authenticate users
• Maintain data confidentional and integrity
  • Hashing, encryption, checksums, digital signatures etc.)
• Access restrictions
  • Only allow access to certain components from certain locations
• Use audit trail attackers can be identified and actions can be restored