IELM 511 Information System design Introduction Part 1

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

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, …) e. Commerce: 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] ?

Considerations in design Most systems will take a set/sequence/series of inputs, do something (useful) provide some output(s) 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

Structured Data Systems Very large percent of Info Systems are DB-backed Very large percent of DB-backed systems use Relational DB’s are ideal when the information to be stored has some structure. 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 Pn. S) - Multiple user-interfaces (views) - Automated reduction of errors via Enforced data integrity and domain constraints - Avoiding concurrent-access anomalies

Modeling of structured information Step 1. Gather all information that must be stored How: interviews with the involved parties, etc. 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.

Example: Banking system 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. 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, Mc. Graw Hill Related web sources: 1. For GUI design: NASA Usability web-site (great resource!) Next: Information Storage for Relational DB’s, ER models