1 / 49

Relational Databases

Relational Databases. Chapter 4. INTRODUCTION. Relational databases underlie most modern integrated AISs. They are the most popular type of database used for transaction processing. What Is a Database?. Efficiently and centrally coordinates information for a related group of files

Télécharger la présentation

Relational Databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Relational Databases Chapter 4

  2. INTRODUCTION • Relational databases underlie most modern integrated AISs. • They are the most popular type of database used for transaction processing.

  3. What Is a Database? Efficiently and centrally coordinates information for a related group of files A file is a related group of records A record is a related group of fields A field is a specific attribute of interest for the entity (record)

  4. FILE VS. DATABASES • Database systems were developed to address the problems associated with the proliferation of master files. • For years, each time a new information need arose, companies created new files and programs. • The result: a significant increase in the number of master files.

  5. FILE VS. DATABASES Master File 1 Fact A Fact B Fact C Fact D Sales Program • This proliferation of master files created problems: • Often the same information was stored in multiple master files. • Made it more difficult to effectively integrate data and obtain an organization-wide view of the data. • Also, the same information may not have been consistent between files. • If a customer changed their phone number, it may have been updated in one master file but not another. Master File 2 Fact A Fact C Fact E Fact F Shipping Program Master File 3 Fact A Fact D Fact E Fact G Billing Program

  6. FILE VS. DATABASES Database Fact A Fact B Fact C Fact D Fact E Fact F Fact G • A database is a set of inter-related, centrally coordinated files. Database Management System Sales Program Shipping Program Billing Program

  7. FILE VS. DATABASES Database Fact A Fact B Fact C Fact D Fact E Fact F Fact G • The database approach treats data as an organizational resource that should be used by and managed for the entire organization, not just a particular department. • A database management system (DBMS) serves as the interface between the database and the various application programs. Database Management System Sales Program Shipping Program Billing Program

  8. FILE VS. DATABASES Database Fact A Fact B Fact C Fact D Fact E Fact F Fact G • The combination of the database, the DBMS, and the application programs that access the database is referred to as the database system. Database Management System Sales Program Shipping Program Billing Program

  9. FILE VS. DATABASES Database Fact A Fact B Fact C Fact D Fact E Fact F Fact G • The person responsible for the database is the database administrator. • As technology improves, many large companies are developing very large databases called data warehouses. • Data Mining • Analysis to identify relationships in the data, new knowledge about business processes, etc. • Example, Credit card issuers efforts to defect fraud Database Management System Sales Program Shipping Program Billing Program

  10. FILE VS. DATABASES Master File 1 Fact A Fact B Fact C Fact D Database Fact A Fact B Fact C Fact D Fact E Fact F Fact G Sales Program Master File 2 Fact A Fact C Fact E Fact F Shipping Program Database Management System Master File 3 Fact A Fact D Fact E Fact G Sales Program Shipping Program Billing Program Billing Program

  11. Advantages of Database Systems • Data Integration • Files are logically combined and made accessible to various systems. • Data Sharing • With data in one place it is more easily accessed by authorized users. • Reporting flexibility: Reports can be revised easily and generated as needed and the database can be easily browsed to research a problem or obtain detailed information underlying a summary report

  12. Advantages of Database Systems • Minimizing Data Redundancy and Data Inconsistency • Eliminates the same data being stored in multiple files, thus reducing inconsistency in multiple versions of the same data. • Data Independence • Data is separate from the programs that access it. Changes can be made to the data without necessitating a change in the programs and vice versa

  13. Advantages of Database Systems • Central management of data: • Data management is more efficient because a database administrator is responsible for coordinating, controlling and managing data • Cross-Functional Analysis • Relationships between data from various organizational departments can be more easily combined. • Example: association between sales and promotional campaigns

  14. Advantages of Database Systems • One-time Data Entry and Storage: • In the data-base approach to data management data are input into the data base once, stored in a particular location and available for use my multiple applications and users

  15. IMPORTANCE AND ADVANTAGES OF DATABASE SYSTEMS • The importance of good data: • Bad data leads to: • Bad decisions • Embarrassment • Angry users

  16. Database Users and Designers Different users of the database information are at an external level of the database. These users have logical views of the data. At an internal level of the database is the physical view of the data which is how the data is actually physically stored in the system. Designers of a database need to understand user’s needs and the conceptual level of the entire database as well as the physical view.

  17. Physical View • Physical views of data • In file-oriented systems, programmers must know the physical location and layout of records used by a program. • They must reference the location, length, and format of every field they utilize. • When data is used from several files, this process becomes more complex.

  18. Physical View

  19. Schemas • Describe the logical structure of a database • Conceptual Level • Organization wide view of the data • External Level • Individual users view of the data • Each view is a subschema • Internal Level • Describes how data are stored and accessed • Description of: records, definitions, addresses, and indexes 4-20

  20. Database Design To design a database, you need to have a conceptual view of the entire database. The conceptual view illustrates the different files and relationships between the files. The data dictionary is a “blueprint” of the structure of the database and includes data elements, field types, programs that use the data element, outputs, and so on.

  21. The Data Dictionary

  22. DBMS Languages • Data Definition Language (DDL) • Builds the data dictionary • Creates the database • Describes logical views for each user • Specifies record or field security constraints • Data Manipulation Language (DML) • Changes the content in the database • Creates, updates, insertions, and deletions • Data Query Language (DQL) • Enables users to retrieve, sort, and display specific data from the database • Report Writer • Simplifies report creation

  23. Relational Database Represents the conceptual and external schema as if that “data view” were truly stored in one table. Although the conceptual view appears to the user that this information is in one big table, it really is a set of tables that relate to one another.

  24. Conceptual View Example

  25. Relational Data Tables Invoice # is PK Customer # is PK Item # is PK Combination of Invoice # & Item # forms the PK

  26. Types of Attributes • Primary key • is the attribute, or combination of attributes, that uniquely identifies a specific row(record) in a table. • Foreign key • is an attribute in a table that is a primary key in another table. • Foreign keys are used to link tables. • Other Non Key Attributes • Store other important data about the entity

  27. Relational Data Tables Primary Keys Foreign Key (Customer # is a Foreign key in the Sales Table because it is a Primary key that uniquely identifies Customers in the Customer Table). Because of this, the Sales Table can relate to the Customer Table (see red arrow above).

  28. Why Have a Set of Related Tables? • Data stored in one large table can be redundant and inefficient causing the following problems: • Update anomaly • Changes to existing data are not correctly recorded. • Due to multiple records with the same data attributes • Insert anomaly • Unable to add a record to the database. • Delete anomaly • Removing a record also removes unintended data from the database.

  29. Database Design Errors • Alternatives for storing data • One possible alternate approach would be to store all data in one uniform table. • For example, instead of separate tables for students and classes at a University, we could store all data in one table and have a separate line for each student x class combination.

  30. Using the suggested approach, a student taking three classes would need three rows in the table. • In the above, simplified example, a number of problems arise. 4-31

  31. Suppose Alice Simpson changes her phone number. You need to make the change in three places. If you fail to change it in all three places or change it incorrectly in one place, then the records for Alice will be inconsistent. • This problem is referred to as an update anomaly. 4-32

  32. What happens if you have a new student to add, but he hasn’t signed up for any courses yet? • Or what if there is a new class to add, but there are no students enrolled in it yet? In either case, the record will be partially blank. • This problem is referred to as an insert anomaly. 4-33

  33. If Ned withdraws from all his classes and you eliminate all three of his rows from the table, then you will no longer have a record of Ned. If Ned is planning to take classes next semester, then you probably didn’t really want to delete all records of him. • This problem is referred to as a delete anomaly. 4-34

  34. Database Design Errors • Alternatives for storing data • Another possible approach would be to store each student in one row of the table and create multiple columns to accommodate each class that he is taking.

  35. This approach is also fraught with problems: • How many classes should you allow in building the table? • The above table is quite simplified. In reality, you might need to allow for 20 or more classes (assuming a student could take many 1-hour classes). Also, more information than just the course number would be stored for each class. There would be a great deal of wasted space for all the students taking fewer than the maximum possible number of classes. • Also, if you wanted a list of every student taking MGMT-3021, notice that you would have to search multiple attributes. 4-36

  36. The solution to the preceding problems is to use a set of tables in a relational database. • Each entity is stored in a separate table, and separate tables or foreign keys can be used to link the entities together. 4-37

  37. Relational Database Design Rules Every column in a row must be single valued Primary key cannot be null (empty) also known as entity integrity IF a foreign key is not null, it must have a value that corresponds to the value of a primary key in another table (referential integrity) All other attributes in the table must describe characteristics of the object identified by the primary key Following these rules allows databases to be normalized and solves the update, insert, and delete anomalies.

  38. Basic requirements of a relational database • Every column(field) in a row must be single valued. • In other words, every cell can have one and only one value.

  39. Note that within each table, there are no duplicate primary keys and no null primary keys. • Consistent with the entity integrity rule. Relationship Table

  40. FK example Not in Salesperson Table Referential integrity would prevent this from happening

  41. RELATIONAL DATABASES • An important feature is that data about various things of interest (entities) are stored in separate tables. • Makes it easier to add new data to the system. • You add a new student by adding a row to the student table. • You add a new course by adding a row to the course table. • Means you can add a student even if he hasn’t signed up for any courses. • And you can add a class even if no students are yet enrolled in it. • Makes it easy to avoid the insert anomaly. • Space is also used more efficiently than in the other schemes. There should be no blank rows or attributes.

  42. Add a student here. • Leaves no blank spaces. • Add a course here. • Leaves no blank spaces. • When a particular student enrolls for a particular course, add that info here. 4-43

  43. RELATIONAL DATABASES • Deletion of a class for a student would cause the elimination of one record in the student x class table. • The student still exists in the student table. • The class still exists in the class table. • Avoids the delete anomaly.

  44. Ned still exists in the student table. • Even if Ned was the only student in the class, ACCT-3603 still exists in the course table. • If Ned Sanders drops ACCT-3603, remove Ned’s class from this table. 4-45

  45. Database Design • There are two basic ways to design well-structured relational databases. • Normalization • Semantic data modeling(chapter 17)

  46. Normalizing Relational Databases • Initially, one table is used for all the data in a database. • Following rules, the table is decomposed into multiple tables related by: • Primary key–foreign key integration • Decomposed set of tables are in third normal form (3NF).

  47. Table 4-14 page 103

  48. Solution page 112

More Related