DATABASE INTRODUCTION

Transcription

1 Introduction The history of database system research is one of exceptional productivity and startling economic impact. We have learnt that from the days of file-based systems there are better ways to handle corporate data. Database Structure The document describing the Database structure is often called a schema. A schema consists of tables. A DB may have one or many tables. Single table databases (S Works; Excel) are called FLAT databases. ost common form of multiple table database is called a RELATIONAL database. Tables are two dimensional with columns (attributes) and rows (records or tuples). Columns contain unique types of data name; address; phone; etc. Rows (Records / Tuples) contain data that pertain to a particular group of data that has something in common. Eg a particular family name. Also, there are relationships between tables (in a relational database) eg one table might contain student details and another one subjects enrolled in. The relationship is that they both belong to the same student. Database Approach A Database is a shared collection of logically related data and a description of this data, Designed to satisfy the information requirements of an organisation. achine: Hardware and Software Human: Program and Procedures Bridge: Data

2 A Database is a self-describing collection of integrated records to meet an organisation s information needs. So a database holds; the organisation s operational data, the relationships between the data collections, the description of this data - the catalog (data dictionary or metadata). The Database anagement System (DBS) A DBS is a software package that enables users; to define and create (using Data Definition Language -DDL), to manipulate and update (using Data anipulation - DL), to control access to their database. (using Data Control Language DBS Terms - DCL), The DBS is the software that interacts with the user s application program and their database. The widely used database language of today is the non-procedural language called Structured Query Language (SQL). Database Views are extra table definitions of portions of the database in the data dictionary, so for security reasons users can see only their view. Eg the Principal of a school would be able to READ all the tables in the school database but not change enrolment or financial details whereas teachers would have READ access to student personal details; read and write access to attendance and results; but NO accesses to financial or enrolment details. Data Integrity; Redundancy & Duplication: Redundancy is where the same data is stored in more than one file leading to a waste of space and possible integrity errors. Redundancy is not necessarily a bad thing in it's own right; however, the database designer must be aware of it. Duplication is where more than one copy (record) of the same data occurs or there is duplication of at least one attribute value. If the data can be removed without causing a loss of data, then this duplication is acceptable. Integrity is the problem of ensuring that the data is accurate. Inconsistencies between two entries that purport to represent the same "fact" is known as an integrity error. This can only arise when there is data redundancy or, worse still, data duplication. (A non-redundant database can also have integrity errors by just having incorrect data stored. An example of this is a miskeyed phone number.) 2

3 TABLE DESIGN FOR Table Name: Primary Key: Related to Table(s): Field Name Data Type Description Field Size Other Field Properties Entities and Entity Relationship Diagrams (ERDs) When a system is first examined we look at the Processes and the Flow of data in the system. This is called the Process odel and we draw a (Logical) Data flow Diagram to represent it. The next step is to draw a data model of the system we require, and associate with that a Data Dictionary. The Data odel we draw is an Entity Relationship Diagram (ERD). An Entity is an object about which we want to store data. An object is something that has a number of attributes that we use to describe it. Entities may include such things as: People: suppliers; customers; students; employees; patients; teachers; lecturers. Physical Objects: printers; buildings; products; cars; books; boats. Data signifying events: orders; deliveries; statements; contracts; invoices; report cards; subject selections; (note that most of these are usually associated with a piece of paper!) Hence an entity such as Student will have attributes such as first name; family name; address; phone number; post code; date of birth and so on. Entities rarely exist by themselves; they are usually linked or related to other entity types. So consider a student at a school. Students select subjects Subjects have students select them. The relationship between the entity types has to do with selecting. Hence we have: Student Selects subject Now this diagram shows a basic relationship, but we have some variations that must be considered. 3

4 . A student might select 5, 6 or 7 subjects in Upper school. 2. A year 0 student may be enrolled in the School, but be absent for one semester (hence no subject selection). 3. A subject may have many students select it (Computer Science). 4. A subject may be offered, but no students select it. Hence when we draw in the links between the entities and relationship we must have a notation to be able to show these possibilities. The Curriculum Council has specified the following standard for Information Systems, and the relationships. Note that it does not support the zero option. Hence when we draw in the links between the entities and relationship we must have a notation to be able to show these possibilities. The Curriculum Council has specified the following standard for Information Systems, and the relationships. Note that it does not support the zero option. Symbols and characteristics DOCTOR ENTITIES: An object, person or thing which has attributes. The identifier is typically in uppercase. Optionally, foreign keys can be indicated in the entity-box: DOCTOR DOCTOR_NAE treats DOCTOR_NAE DOCTOR_ADDRESS DOCTOR_PHONE RELATIONSHIPS: These exist between entities, and can be of four forms (or degrees, or cardinality): one-to-one (:), one-to-many (:, or : in Access ), many-to-one (:, or : in Access ) and many-to-many (:N). Note that there cannot be :N relationships in a relational database. In this circumstance, the relations need to be resolved to form two or more : or : relationships. The relationship type is written in the diamond in lowercase. The relationship degree (or cardinality) is written at the extremities if the connectors to the entities. ATTRIBUTES: are typically written alongside the entity to which they belong, with the primary key underlined. Foreign keys should have the same identifiers in each entity's attributes.. Sample ERDs StockNumber StockItemDescription SupplierCode FK Stock is supplied by Suppli er SupplierCode SupplierName SupplierSuburb Name Address DateOfBirth LicenceNumber FK Driver holds Licenc e LicenceNumber Class ExpiryDate Photo 4

5 The above example shows a composite primary key for the driver. Sample ERD This example is based upon that given in Kendall & Kendall (992) p. 525 DOCTOR_NAE DOCTOR_ADDRESS DOCTOR_PHONE DOCTOR treats PATIENT_NAE PATIENT_ADDRESS PATIENT_PHONE DOCTOR_NAE INSURER_NAE INSURANCE_NO PATIENT undergoes TREATENTS DESCRIPTION DATE SYPTOS PATIENT_NAE PRODUCT_NAE insured by include INSURER_NAE INSURER_ADDRESS ENTITLEENT_DESC INSURANCE_NO EDICAL INSURER PRESCRIPTIONS PRODUCT_NAE DOSE TIING Data dictionary (Defintion courtesy of A data dictionary is a collection of descriptions of the data objects or items in a data model for the benefit of programmers and others who might need to refer to them. A first step in analysing a system of objects with which users interact is to identify each object and its relationship to other objects. This process is called data modelling and results in a picture of object relationships. After each data object or item is given a descriptive name: ü its relationship is described (or it becomes part of some structure that implicitly describes relationship); ü the type of data (such as text or image or binary value) is described; ü possible predefined values are listed, and ü a brief textual description is provided. This collection can be organised for reference into a book called a Data Dictionary. When developing programs that use the data model, a data dictionary can be consulted to understand where a data item fits in the structure, what values it may contain, and basically what the data item means in real-world terms. For example, a bank or group of banks could model the data objects involved in consumer banking. They could then provide a data dictionary for a bank's programmers. The data dictionary would describe each of the data items in its data model for consumer banking (for example, "Account holder" and ""Available credit"). 5

6 Normalisation and the Process of Normalisation to 3NF The process of normalisation is intended to achieve the elimination of redundant or repeating data within a relation (table). (NF) - the reduction or elimination of repeating groups (2/3NF) - non-dependencies upon the primary keys Normalisation theory is set around the concept of normal forms. A relation (table) is said to be in a particular normal form if it satisfies the criteria of that form. A relation which is in a particular normal form (say NF) can be broken down into a set of tables that may be in 2NF by applying the constraints for that normal form. Definition of 3rd Normal Form A relation is in 3NF if and only if the non-key attributes (if any) are: a) utually independent, and b) Fully dependent on the primary key Non-key attribute: does not participate in the primary key of the relation concerned. utually independent: when two or more attributes are not functionally dependent on any combination of the others Alternate definition of 3rd Normal Form A relation is in 3NF if and only if each tuple (record) consists of a primary key value that identifies some entity, together with a set of zero or more mutually independent attribute values that describe the entity in some way. Definition of NF (from Date, P539) A relation is in first normal form if and only if all underlying simple domains contain atomic values only. Definition of 2NF A relation is in second normal form if and only if it is in NF and every non-key attribute is fully dependent on the primary key. Definition of 3NF A relation is in third normal form if and only if it is in 2NF and every nonkey attribute is non-transitively dependent on the primary key. Definition from Whatis.com Normalise In creating a relational database, to "normalise" data is to organise it in tables in such a way that the results of using the database are always unambiguous and as intended. Normalisation may have the effect of reducing the duplication of data items within the database and often results in the creation of additional tables. Normalisation is typically a refinement process after the initial exercise of identifying the data objects that should be in the database, identifying their relationships, and defining the tables required and the columns within each table. A simple example of normalising data might consist of a table showing: Customer Item purchased Purchase price Thomas Shirt $40 aria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25 If this table is used for the purpose of keeping track of the price of items and you want to delete one of the customers, you will also delete a price. Normalising the data would mean understanding this and solving the problem by dividing this table into two tables, one with information about each customer and a product they bought and the second about each product and its price. aking additions or deletions to either table would not affect the other. 6

7 Normalisation degrees of relational database tables have been defined and include: First normal form (NF). This is the "basic" level of normalisation and generally corresponds to the definition of any database, namely: It contains two-dimensional tables with rows and columns. Each column corresponds to a sub-object or an attribute of the object represented by the entire table. Each row represents a unique instance of that sub-object or attribute and must be different in some way from any other row (that is, no duplicate rows are possible). All entries in any column must be of the same kind. For example, in the column labelled "Customer," only customer names or numbers are permitted. Second normal form (2NF). At this level of normalisation, each column in a table that is not a determiner of the contents of another column must itself be a function of the other columns in the table. For example, in a table with three columns containing customer ID, product sold, and price of the product when sold, the price would be a function of the customer ID (entitled to a discount) and the specific product. Third normal form (3NF). At the second normal form, modification are still possible because a change to one row in a table may affect data that refers to this information from another table. For example, using the customer table just cited, removing a row describing a customer purchase (because of a return perhaps) will also remove the fact that the product has a certain price. In the third normal form, these tables would be divided into two tables so that product pricing would be tracked separately. 7