2015 2016
Phil Smith
Today Learning outcomes LO2 On successful completion of this unit you will: 1. Be able to design and implement relational database systems. 2. Requirements. 3. User Interface. I am going to start with requirements.
Learning outcomes LO2 What are requirements: requirements specification (Business). relational requirements (Technical). other requirements e.g. need to integrate with legacy systems (Technical). future requirements, timescales, costs (Business). The scenario that we have been working on has a fairly! clear set of business requirements. This will need to be dissected and re purposed into a more technical requirement in order for the development goals to be identified.
Learning outcomes LO2 Business requirement: MWS, a small business wishing to sell phone cases via an e commerce system. Brief to say the least. We know what an e commerce should do e.g. we all buy things online (Amazon etc). So we know what the user experience should be like. Ordinarily we would seek further detail from the business, but, they have little knowledge (by their own admission).
Learning outcomes LO2 We have already identified the information requirements based upon the static website content and by doing an ERM exercise followed by a normalisation exercise based upon sample data held in excel files and our identification of information requirements. So we already have identified the relational requirements (Technical).
Learning outcomes LO2 The company does not have any other systems so whilst we consider integration, for this requirement we can ignore this one. For future requirements, whilst unknown at this time, we have made our database design scalable by normalising the data. As for timescales and costs which, tend to go together, the business should have done a cost benefit analysis to justify the development time and thus the cost of development. Of course there are other costs to be incurred e.g. any training for staff, cost of hardware/software, hosting, disaster recovery etc.
Logical model recap Logical Database Design Any database should be designed with the end user in mind. Logical database design, also referred to as the logical model, is the process of arranging data into logical, organized groups of objects that can easily be maintained. The logical design of a database should reduce data repetition or go so far as to completely eliminate it. After all, why store the same data twice? Naming conventions used in a database should also be standard and logical.
Logical model recap What Are the End User's Needs? The needs of the end user should be one of the top considerations when designing a database. Remember that the end user is the person who ultimately uses the database. There should be ease of use through the user's front end tool (a client program that allows a user access to a database), but this, along with optimal performance, cannot be achieved if the user's needs are not taken into consideration.
Logical model recap Some user related design considerations include the following: What data should be stored in the database? How will the user access the database? What privileges does the user require? How should the data be grouped in the database? What data is the most commonly accessed? How is all data related in the database? What measures should be taken to ensure accurate data?
Normalization Recap on designs: When designing a relational database, there is a need to "normalize" the database. There are different degrees of normalization, but in general, relational databases should be normalized to the "third normal form or better still Boyce Codd normal form BCNF). Simply put, this means that the attributes (i.e. fields) in each table should "depend on the key, the whole key and nothing but the key".
Advantages of normalization Provide indexing. When the developer creates a primary key constraint, SQL Server will automatically create a unique clustered index on the column(s) for which the constraint has been created. In most cases, the creation of a clustered index will speed up data access and may increase insert, update, and delete performance. When you're creating primary keys, Microsoft recommends using integer primary keys because SQL Server is optimized to sort and index them.
Advantages of normalization Normalization is used for mainly two purpose, 1. Eliminating redundant(useless) data. 2. Ensuring data dependencies make sense i.e. data is logically stored.
Dis advantages of normalization Easy to over normalize your data. Creation of more tables. Require more joins to re combine the data. Poor database performance (due to more tables/joins etc.) May have to sacrifice some redundancy to improve performance (de normalisation).
Issues relating to degrees of normalization Minimize modification anomalies. Without Normalization or if normalization is not done to 3nf, it becomes difficult to handle and update the database, without facing data loss. Insertion, Updating and Deletion anomalies are very frequent if Database is not Normalized to 3nf or not normalised at all. Modification anomalies arise when data is inserted, updated, or deleted, and information is lost in unexpected ways.
Issues relating to degrees of normalization To understand these anomalies let us take an example of Student table. Update Anomaly : To update address of a student who occurs twice or more than twice in a table, we will have to update S_Address column in all the rows, else data will become inconsistent. Insert Anomaly : Suppose for a new admission, we have a Student id(s_id), name and address of a student but if student has not opted for any subjects yet then we have to insert NULL there, leading to Insertion Anomaly. Delete Anomaly : If (S_id) 401 has only one subject and temporarily he drops it, when we delete that row, entire student record will be deleted along with it. To help avoid these problems, normalize to at least 3 rd normal form.
Implementation The leading vendors of RDBMS are listed below: **** RDBMS Vendors **** **** RDBMS Product **** Computer Associates INGRES IBM DB2 INFORMIX Software INFORMIX Oracle Corporation Oracle Microsoft Corporation MS Access Microsoft Corporation SQL Server MySQL MySQL NCR Teradata PostgreSQL Dvlp Grp PostgreSQL Sybase Sybase 11
Common Data types data types; basic data types common to databases. General http://www.w3schools.com/sql/sql_datatypes_general.asp SQL Data Types for Various DBs http://www.w3schools.com/sql/sql_datatypes.asp
Physical modelling Physical modelling involves the actual design of a database according to the requirements that were established during logical modelling. Physical modelling deals with the conversion of the logical, or business model, into a relational database model. When physical modelling occurs, objects are being defined at the schema level. A schema is a group of related objects in a database. A database design is normally associated with one schema.
Physical modelling To implement your physical model, which RDBMS are you going to use? 1. Microsoft Access 2013 2. Microsoft Sql Server 2014 3. MySql With MySql you can implement locally provided XAMPP is installed or you can use our hosting site. LO2 2.2 Build a relational database to meet a given requirement.
Physical modelling The tools we can use are 1. Microsoft access 2013 2. Sql Server Management Studio 3. phpmyadmin 4. MySql workbench LO2 2.2 Build a relational database to meet a given requirement.
Physical modelling Database tools and techniques quality of the data 1. Default values 2. Validation that reformats data e.g. Change names to proper case etc. 3. Validation that prevents incorrect data being entered e.g. date cannot be less than today. 4. Referential integrity a rule on the database that states a foreign key must have a matching primary key in the related table; however, this does not mean it is the correct key! 5. Table/field check constraint, a database rule to ensure data is only accepted into the specified field if it obeys the check constraint i.e. value must be greater than zero. Whilst some of these are specified at the database table/field level, others are specified at the HCI level/business layer level.
Implementation Task There is a task in lab 06 which we will do at the end.
Implementation SQL SQL defines the following data languages to manipulate data of the RDBMS. 1. DDL: Data Definition Language 2. DML: Data Manipulation Language 3. TCL: Transaction Control Language 4. DCL: Data Control Language 5. DQL: Data Query Language
Implementation DDL 1. Data Definition Language Command create alter truncate drop rename Description to create new table or database for alteration delete fields from table to drop a table to rename a table
Implementation DDL 1. Create the Customer table using DDL in Access 2013 CREATE TABLE Customer ( Customer_ID Number, Title Number, Firstname TEXT(50) NOT NULL, Surname TEXT(50) NOT NULL, Address TEXT(10) NOT NULL, City TEXT(50) NOT NULL, PostCode TEXT(10) NOT NULL, DateCreated DATE, Constraint Customer_PK Primary Key (Customer_ID)); Microsoft Access has restrictions: No defaults, autonumber etc
Implementation DDL 1. Create the Customer table using DDL in MySql CREATE TABLE IF NOT EXISTS `customer` ( `Customer_ID` int(11) NOT NULL, `Title` int(11) NOT NULL, `Firstname` varchar(50) NOT NULL, `Surname` varchar(50) NOT NULL, `Address` varchar(100) NOT NULL, `City` varchar(50) NOT NULL, `Postcode` varchar(10) NOT NULL, `DateCreated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP) ENGINE=InnoDB DEFAULT CHARSET=latin1; ALTER TABLE `Customer` ADD PRIMARY KEY (`Customer_ID`);
Implementation DDL Task 2 1. Amend the mistake in the Access Customer table address field (only 10 characters long oops). Alter TABLE Customer Alter Address TEXT(100) NOT NULL ;
Implementation DDL Task Task 3 1. Use DDL to create the other tables from your assignment 1 task 3. 2. Keep copies of your DDL scripts and take screen shots of the final table as these will be required for assignment 2.
Implementation DML 1. DML commands are not auto committed. It means changes are not permanent to the database, they can be rolled back. (see TCL) The updates need to be committed. Command insert update delete merge Description to insert a new row to update existing row to delete a row merging two rows or two tables
Implementation DML 1. Inserting a new row in to the Customer table. Method 1 Insert into Customer (1, Wayne, Rooney, Old Trafford, Manchester, M16 ORA ) Here data for every column (not autoincrement fields) must be supplied in the sequence specified in the table. Method 2 Insert into Customer(CustomerTitle, Firstname, SurName, Address, City, PostCode) Values (1, Wayne, Rooney, Old Trafford, Manchester, M16 ORA ) Not all columns need to be included (except mandatory ones) Method 2 is my preferred option.
Implementation DML 1. Updating an existing row in the Customer table. Assuming we know the primary key! Update Customer Set PostCode = M16 0RA Where [Customer ID] = 15018
Implementation DML 1. Delete an existing row in the Customer table. Delete from Where [Customer ID] = 15018 Caution! If you do not specify a where clause then all rows in the table will be deleted. If this table has relationships and you have added cascading deletes? You could delete an awful lot of data.
Implementation TCL 1. TCL: Transaction Control Language Here you can group database updates together and then commit the changes should everything look ok. Begin Tran Insert/update/delete statements.. Commit Tran or rollback Tran End Tran
Implementation DCL 1. DCL: Data Control Language With DCL you either Grant or Revoke permissions for logins defined in the RDBMS. This provides authority to allow/deny access to 1. Specific tables/fields 2. Specific View/stored procedures 3. Most database objects. This matters more when user security is handled by the RDBMS rather than the application. It is very common to provide ownership of a database to a single application login in the database, then, user authentication is done via ldap and application functions.
Implementation DQL 1. DQL: Data Query Language The select query is used to retrieve data from tables. It is the most used SQL query. We can retrieve complete tables, or partial by mentioning conditions using WHERE clause. Select Firstname, SurName From Customers Where PostCode = BD3 6AZ (only rows that match the condition) Select Firstname, SurName From Customers (All rows) Select * from Customers (All columns and all rows) A special character asterisk * is used to address all the data(belonging to all columns) in a query.
Lab Session 06 Now do the Lab 06 exercises. These tasks can be used as evidence assignment 2. This can be done in open lab.
Summary What have we learnt today? Over to you!