IELM 511: Information System design Introduction Part 1. ISD for well structured data – relational and other DBMS ISD for systems with non-uniformly structured data Part III: (one out of) Basics of web-based IS (www, web2.0, …) Markup’s, HTML, XML Design tools for Info Sys: UML API’s for mobile apps Security, Cryptography IS product lifecycles Algorithm analysis, P, NP, NPC Info storage (modeling, normalization) Info retrieval (Relational algebra, Calculus, SQL) DB integrated API’s

Examples of Info Systems Enterprise Resource Planning (ERP): Demand forecasting (uses statistics) Inventory tracking (uses: Database) Materials requirement planning Operations scheduling Accounting Personnel data management (employees, salary/benefits, leave data,..) Financial: Banks, Investment banks Financial information (Bloomberg, …) eCommerce: Auctions, Online retail, … Services, … Dissemination (Internet, Intranet, Web-search, …) …

Basics of IT applications Stand-alone application: computer program [input  do something  output] Complex applications: Many interacting computer programs Fundamental component: IT applications take inputs (from sensors, humans) Most IT applications provide outputs (to actuators, humans)

Fundamental requirements of Info Systems 1. Correctness Must do what it is designed to do Errors/inaccuracies/Inconsistencies 2. Efficiency How fast does it do the task (computing time, convergence, …) 3. Convenience of use How good is the System-Human Interface [UI or GUI] ?

Most systems will take a set/sequence/series of inputs, do something (useful) provide some output(s) Considerations in design Design of the Info Systems depends on: 1. How ‘well structured’ are the inputs ? 2. Objectives (Correctness ? Speed / Efficiency ?) Give examples of Info Sys where speed is more important than correctness

Very large percent of Info Systems are DB-backed Very large percent of DB-backed systems use Relational DB’s Relational DB’s are ideal when the information to be stored has some structure. Structured Data Systems Examples: - Banks (customer accounts, loans, …) - Institutions (students, courses, …) - Industry (MRP systems, Accounting, Personnel, …) Why not just store all the data in Word, Excel files ?

Structured Data Systems requirements - Information consistency and controlled redundancy (**) - Controlled access of information (e.g. Personnel data) - Faster access (e.g. 1,000’s price checks per sec in PnS) - Multiple user-interfaces (views) - Automated reduction of errors via Enforced data integrity and domain constraints - Avoiding concurrent-access anomalies

Step 1. Gather all information that must be stored How: interviews with the involved parties, etc. Modeling of structured information Step 2. Determine how to organize all the information Objectives:All info must be captured; Info sys should obey the requirements (previous slide) How: ER diagrams  Relational model  Normalized relational model.

Bank is organized in branches. Each branch is located in a particular city and identified by a unique name. The bank monitors the assets of each branch. Example: Banking system Customers are identified by their SSN (equiv to HKID). The bank stores each customer’s name and address. Customers may have accounts, and can take out loans. A customer may be associated with a particular banker, who may act as a loan officer of personal banker for that customer. Bank employees are also identified by SSN. The bank stores the Name, address, phone #, start day of employment of each employee, the name of all dependents of the employee, and the manager of the employee. The bank offers two types of accounts: savings and checking. Accounts can be held by more than one customer, and a customer may have many accounts. Each account has a unique account number. We store each account’s balance, and the most recent date when the account was accessed by each customer holding the account. Each savings account has an interest rate, and overdrafts are recorded for each checking account. A loan originates art a particular branch, and is held by one or more customers. Each loan has a unique number. For each loan, the bank stores the loan amount and the payments (date and amount). Payment numbers are not unique, but a payment number uniquely identifies a payment for a specific loan.

Bank IS design considerations How to store all the data related to this Bank’s IS problem ? Is this information provided by the bank complete, or did they miss out some detail that will affect how we store the information ? In the next lecture, we shall see how to use ER models to organize this Info.

References and Further Reading My lectures on DB’s will use the following text book: Silberschatz, Korth, Sudarshan, Database Systems Concepts, McGraw Hill Related web sources: 1. For GUI design: NASA Usability web-site (great resource!)web-site Next: Information Storage for Relational DB’s, ER models