Presentation is loading. Please wait.

Presentation is loading. Please wait.

Managing Organizational Data. Data Management in the Past Admitting ID = 8-digit # Clinic ID = Alphanumeric Laboratory ID = 9-digit # Methodist Hospital.

Similar presentations

Presentation on theme: "Managing Organizational Data. Data Management in the Past Admitting ID = 8-digit # Clinic ID = Alphanumeric Laboratory ID = 9-digit # Methodist Hospital."— Presentation transcript:

1 Managing Organizational Data

2 Data Management in the Past Admitting ID = 8-digit # Clinic ID = Alphanumeric Laboratory ID = 9-digit # Methodist Hospital What problems do you see here?

3 Problems with Flat Files uRedundancy uOf Data Stored uOf Programs uduplicate input, processing, output umany programs doing the same thing on different data ex: every program that produces a listing has to open a file, read the records and write out to paper uLack of Standardization uData Names udifferent names for same data usame name for different data uData Formats uSecurity uNew Reports = New Programs

4 Database Mgt Systems (DBMS) uDatabase: Repository for data uMgt System: uSoftware that controls db uAllows database to be ACCESSED, MAINTAINED and PROTECTED uDBMS: software + repository

5 DBMS Separates Data from How it is Used DBMS Repository Software Programs that use DBMS People using Programs People using DBMS directly

6 Features in a Typical DBMS uAbility to Maintain Database uCreate and populate tables (see next 2 slides) uAdd records (see data entry form slide) uDelete or Modify records (see query languages slide) uAbility to Access Data in Database uQuery (see simple query slide) uReports (see report from query slide) uProgramming in a Database uMacros uApplication Programs uAbility to uFine-tune DBMS performance uEnsure data integrity (see slide on integrity)

7 Tables in a Database Primary Key = unique identifier

8 Table Structure (creates fields)

9 Add Records - Data Entry Screen

10 Simple Query Query Setup Execution of the query Note: this is a pseudotable -- it doesnt take up space on disk Could also specify how to sort records Tell system what to filter out

11 Query Languages uSQL uSelect -- pull info from one or more tables uSELECT EMPID,FIRST,LAST FROM EMPLOYEE WHERE OVERTIME > 0 ORDER BY OVERTIME uUpdate Query change records in a table uex: raise prices, give raises uDelete Query uNatural Query Language uWhich shipments are overdue? uTranslated by DBMS into SQL

12 Report based on a table or a psuedo table (from a query)

13 Typical TPS Database uWill have these types of tables uMaster tables ufor entities of the organization ulike master files in flat file system uTransaction tables ufor relationships between entities ulike transaction files uLookup tables uconnect a code to detailed info uex: Dept AC = Accounting in Suite 404 uAnd allow joining of tables uwhen need info from multiple tables

14 Relationship Map Arrows indicate table joining - records in each table are matched up using the key(s) in bold

15 Joining Tables in a Query uJoin uCreates a new pseudotable from multiple existing tables by… uMatching up ID numbers uHow it works uAll the tables must have one field in common uThe common must be an ID-type field uYou tell the DBMS to join these ID fields in the different tables uThe DBMS will do the matching and create the Pseudotable

16 Good database design uGoals are to… uMinimize storage uBy minimizing redundancy uMaximize accessibility uBy ensuring that tables can be joined uMaximize readability uNaming conventions uE-R Diagrams are a design tool uFirst capture reality in diagram uThen translate reality to tables

17 Entity-Relationship Diagrams uEntities uThe things or events to be stored in database uEach entity will get one or more tables Ex: Department table, Employee table u Fields or attributes are sometimes also shown uRelationships u Connections between entities) Ex: Department has Employees Department Employees has SSN, Name, Salary DeptID Location Supervisor Fields RelationshipEntity Fields

18 Relationships between Entities uThe type of relationship determines… uThe number of tables needed in DB uThe next step is to determine what type of relationships are there uThere are 3 types of relationships uOne-to-One Relationship Employee Computer uOne-to-Many Relationship Department Employee uMany-to-Many Relationship Supplier Product

19 One To One Relationship uNeed to add reference key to one of the tables pointing to the other uEmployee and Computer tables uPrimary key of Employee table is EmpID uComputer table has EmpID too u Reference field that points to Employee Table Joi n Note: Putting Serial No in Employee table would also work

20 Pseudotable (after join) uWhen query is executed, the DBMS… ufinds all the records in Computer table uthat have the same EMPID as a record in the Employee table ujoins the two records u and puts them in pseudotable uNotice that EmpID #1 is missing uOnce joined can use info from either table uex: create a computer listing w/ names EmpIDFirstLastDeptMachineSerial 2CarolDoeACGateway 2000 333-44 3BarbJonesMKCompac333-45

21 One to Many Relationships DPTID ADDR NAME Department Table (one table) MKSuite 1 Marketing ACSuite 2 Accounting Employee Table (many table) EMPIDFIRSTLAST DEPT Why cant you put EmpID in the Department table?

22 One to Many Join Result New Pseudo Table Notes: Redundant information in Pseudotable DeptID, Suite #, Name because of one to many relationship No redundancy in original Department Table Limited redundancy in original Employee Table (only Dept code) Can still use fields from either table for report ex: Directory of employee names grouped by Department EMPID FIRST LAST DPTID ADDR NAME

23 Original Relationship is many to many Many to Many Relationship Product Table Supplier Table Product-Supplier Relationship Table You need 3 tables, Many to Many Relationship becomes two different one to many relationships SID NameCityStatus PID SID P1 P2 P3 S1 S2 S1 S2 (Product 1 supplied by Supplier 1 & 2. Supplier 1 sells Product 1 & 2) PID NamePrice Qty

24 Basic Data Concepts

25 Relationship-Table Guidelines uOne-to-One Relationship uCan put both entities in one table uOr create two tables uone table must have a reference field that points to the other table uOne-to-Many Relationship uneed two tables ua table for each entity, plus reference in the many table pointing to the one table uMany-to-Many Relationship uneed 3 tables ua table for each entity, plus a relationship table uand links from each entity to its side of the relationship table

26 DBMS Generations uEarly Dbs: Hierarchical, Network uRelational (most prominant) ueach entity is stored in a table uconnect entities only when need to uObject Oriented uentities stored in objects (data + actions) uused for multimedia, complex text uex: images, engineering specifications uHypermedia uChunks of information (text, multimedia) uOne chunk has links to other chunks

27 Distributed Databases uOriginally: one mainframe w/ central db uWith minis, PC, mainframes, etc. uDistribute Db to different sites ulocal, departmental, regional, headquarters db uinvisible to user

28 Database Architecture uSeveral layers of databases on Db servers uOperational databases (TPS data) u goal: speed, accuracy uData Warehouse u snapshot of operational db + previous years data uData Marts u Analytical databases for specific functional areas uBased on the concept of Data Mining utheres informative gold in them thar dbs!

29 DBMS and Database Integrity uFeatures May Vary but all vendors will have... uData Validation uConcurrency and Locking Features uPassword Management Features

30 Publishing Info for DB Book Title: Managers Guide to Database Technology Author: Michael Blaha Publisher: Prentice Hall ISBN: 0130304182

Download ppt "Managing Organizational Data. Data Management in the Past Admitting ID = 8-digit # Clinic ID = Alphanumeric Laboratory ID = 9-digit # Methodist Hospital."

Similar presentations

Ads by Google