Database Concepts

1. What is DBMS? Database Management System is a set of computer programs that controls the creation, maintenance, and the use of a database. What is a Schema? A description of data in terms of data model is called a schema. In the relational model, the schema for a relation specifies its name, the name of each field (or attribute or column), and the type of each filed. Example for student information in a university database may be stored in a relation with the following schema: Student ( sid: string, name: string, login: string, age: integer, gpa: real) What is DDL? A data definition language (DDL) is used to define the external and conceptual schemas. What is a Database? A database is a collection of data. Data in the database:is integrated Can be shared Can be concurrently accessed The database systems are designed to: Define structures for the storage of data

2. Provide mechanisms for the manipulation of data

3. Ensure the safety of the data stored, despite system crashes or attempts at unauthorized access

4. Share data among the different usersIn short, database systems are designed to manage large volumes of data. The first general-purpose DBMS, designed by Charles Bachman at General Electric in the early 1960s, was called the Integrated Data store. In the late 1960s, IBM developed the information Management System (IMS) DBMS. File System Interface versus DBMS Interface In the traditional file approach, data is stored in flat files which are maintained by the file system, under the operating systems control. The end users use the application programs to perform specific tasks. All application programs go through the file system to access the data stored in these flat files. In the DBMS approach, all requests to use the data stored in the database are handled by the DBMS. The end user can use either the application programs or the standard SQL to access the data. Flat Files: A flat file is a file containing records that has no structured interrelationship. Files used in programming fundamentals projects were essentially flat files. SQL: (Structured Query Language). A language used by relational databases to query, update and manage data. The data in the database can be shared. Sharing means individual pieces of data in the database can be shared among different users. Points to Remember: Disadvantages of the traditional file approach: Data Security – Data easily accessible by all and therefore not secure

5. Data Redundancy – Same data is duplicated in two or more files which may lead to update anomalies

6. Data Isolation – All the related data is not available in one file. Thus writing a new application program is difficult

7. Program / Data Dependence – Application programs are data dependent. It is impossible to change the physical representation (how the data is physically represented in storage) or access technique (how it is physically accessed) without affecting the application.

8. Lack of Flexibility – Only pre-determined request for information can be met. It is not flexible to satisfy unanticipated queries.

9. Concurrent Access Anomalies – Same piece of data is allowed to be updated simultaneously which leads to inconsistencies.DBMS ensures the following Application programs and queries are data-independent. They do not depend on any one particular physical representation of data in secondary storage of access technique

10. Allows for sharing of data among different users. Users are also able to access the database concurrently without facing the issues of inconsistent data.

11. Controls redundancy and inconsistency

12. Provides secure access to that database

13. Enforces integrity constraints (also known as business rules) by preventing the entity of invalid information into the database.

14. Enables backup and recovery from system crashes.Queries: - A query is essentially a request that a user makes on the database. Integrity Constraints: A set of rules to ensure the correctness and accuracy of data. Types of Databases There are two generic database architectures: centralized and distributed. Centralized: All data is located at a single site. Allows for greater control over accessing and updating data Distributed: The database is stored on several computers from personal computers up to mainframe systems. Computers in a distributed system communicate with one another through various communication media such as high speed networks or telephone lines. Distributed databases are geographically separated and managed. DBMS Architecture Most commercial databases are based on the three-level architecture model called the ANSI/SPARC (American National Standards Institute/Standard Planning and Requirements Committee) model. Database architecture is in there levels. Those are External/View Level

15. Conceptual Level

16. Internal LevelThe overall design of the database is called database schema. Schemas are not changed frequently. In general, database systems support one internal schema, one conceptual schema and several external schemas. External / View Level: Many users of the database system are not concerned with all the information in the database. Instead, they need to access only a part of the database. The external level of abstraction simplifies the end users interaction with the system. The system may provide many views for the same database. Conceptual / Logical Level: The conceptual level describes what data are stored in the database, and what relationships exist among those data. This level is used by the Database Administrator, who in turn decides what information must be kept in the database. Internal / Physical level: The internal level is the lowest level of abstraction and describes the data storage and access methods. Database Administrator may be aware of certain details of the physical organization of the data. Guidelines to select a primary key: Give preference to numeric columns(s). The search algorithm performs better when the primary key is numeric

17. Give preference to a single attribute. The search algorithm gives better output with a single attribute primary key than with a composite attribute primary key

18. Give preference to the minimal composite key. A composite key is a collection of two or more attributes.

19. Primary keys are chosen according to business convenience.DBMS Users End Users: Works at the external level and generally makes updates to the database or executes queries on the database. Application Programmer: Writes application programs. Database Administrator: Defines the conceptual, internal and external schema, control access privileges to/from users and ensures the consistency of the database. Different types Keys Candidate/Primary Key: - A Primary key is a set of one or more attributes that can uniquely identify a row in a given table. Foreign Key: - A foreign key is a set of attributes the values of which are required to match the values of a candidate key in the same or another table. The foreign key attributes can have duplicate or null values. Self Referencing: - A table might include a foreign key, the values of which are required to match the value of a candidate key in the same table. This is known as self referencing. Non –Key Attributes: The attributes other than the primary key attributes in a table/relation are called non-key attributes. Data Models A data model is a conceptual toll to describe data, data relationships, data schematics and consistency constraints. Two of the widely used data models are Object Based Logical Model

20. E-R Model

21. Record Based Logical Model

22. Hierarchical Data Model

23. Network Data Model

24. Relational Data Model

25. Structural TerminologyRDBMS Relational Database Management System is a type of DBMS that stores data in the form of related tables. Databases are widely used in real life applications such as: Airlines: for reservations and schedule information.

26. Banking: for customer information, accounts, loans and banking transactions

27. Universities: For student information, course registrations and grades.

28. Telecommunications: For keeping records of calls made, generating monthly bills, maintaining balances on prepaid calling cards and storing information about the communication networks.

29. Sales: For customer, product and purchase information in any industry.Entity Relationship model (E-R Model) Entity relationship Diagram (ERD) was first defined in 1976 by peter chen. Since then Charles Bachman and James Martin have added some small refinements to the basic ERD principles. Entity: Entity is a common word anything real or abstract, about which we want to store data. Entity types fall into five categories: roles, events, locations, tangible things or concepts. Attribute: An attribute is a characteristic property of an entity. An entity could have multiple attributes. Example: For an entity car, the attributes would be the color, model number, number of doors, right or left hand drive etc. Relationship: Relationship is a natural association that exists between one or more entities. Cardinality of a Relationship: Cardinality of relationship defines the type of relationship between two participating entities. Example: One employee can take many books from library. One book can be taken by only one employee. Cardinality of relationship between employee and book is “one to many”. There are four types of cardinality relationship. One to One Relationship

30. One to Many Relationship

31. Many to One Relationship

32. Example: Many employees can work for only one department but one department can have many employees.

33. Many to Many Relationship

34. Example: One Student is enrolled for many courses and one course is enrolled by many students.E-R Diagram Notations Entity: an Entity is an object or concept about which business user wants to store information Weak entity: A weak entity is dependent on another entity to exist. Example bank branch depends upon bank name for its existence. Without bank name it is impossible to identify bank uniquely. Attributes: Attributes are the properties or characteristics of an entity. Key attribute: A key attribute is the unique (primary key), distinguishing characteristic of the entity. Multi valued attribute: A multi valued attribute can have more than one value. For example, an employee entity can have multiple skill values. Derived attribute: A derived attribute is based on another attribute. For example, an employee’s monthly salary is based on the employee’s basic salary and house rent allowance. Relationships: Relationships illustrate how two entities share information in the database structure. A model is an abstract from of any system or process that hides the unnecessary details, while highlighting those details important to the application. This will help the business users to visualize the application before it is developed and suggest changes, if it is not as per their requirement. Modeling the databases using E-R diagrams is called as E-R Modeling. This technique is also called as Top-Down approach, because one need not identify all the attributes to model the system using this technique. Steps in E-R Modeling Usually the following six steps are followed to generate E-R Models. Identify the entities: Look for general nouns in requirements specification document which are of business interest to business users.

35. Find relationships: Identify the natural relationship and their cardinalities between the entities.

36. Identify the key attributes for every entity: Identify the attribute or set of attributes which can identify instance of entity uniquely

37. Identify other relevant attributes: Identify other attributes which are interest to business users and want to store the information in database.

38. Complete E-R diagram: Draw complete E-R diagram with all attributes including primary key.

39. Review your results with your business users: Look at the list of attributes associated with each entity to see if anything has been omitted.Advantages of E-R Modeling Easy to understand. Represented in business users language. Can be understood by non-technical specialist.

40. Intuitive and helps in physical database creation.

41. Can be generalized and specialized based on needs.

42. Can help in database design

43. Gives a higher level abstraction of the system.What is normalization? Normalization is the process of efficiently organizing data in a database. There are two goals of the normalization process: Eliminating redundant data (for example, storing the same data in more than one table)

44. Ensuring data dependencies make sense (only storing related data in a table). OR Organize data into an efficient and logical structure.Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored. First Normal Form (1NF) First Normal form sets the very basic rules for an organized database: Eliminate duplicate columns from the same table.

45. Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key).Second Normal Form (2 NF) Second normal form further address the concept of removing duplicative data: Meet all the requirements of the first normal form.

46. Remove subsets of data that apply to multiple rows of a table and place them in separate tables.

47. Create relationships between these new tables and their predecessors through the use of foreign keys.Third Normal Form (3 NF) Third normal form goes one large step further: Meet all the requirements of the second normal form.

48. Remove columns that are not dependent upon the primary key.Boyce Codd Normal Form (BCNF) A relation is said to be in Boyce Codd Normal Form if and only if all the determinants are candidate keys. BCNF relation is a strong 3NF, but not every 3NF relation is BCNF. Let us understand this concept by using Result table structure. In the above table we have two candidate keys namely Student# Course# and course# Emailid. Course# is overlapping among those candidate keys. Hence these candidate keys are called as “overlapping candidate keys”. The non-key attribute, Marks is non-transitively and fully functionally dependant on key attributes. Hence this is in 3NF. But this is not in BCNF because there are four determinants in this relation namely: Student# (Student# decides EMailid)

49. Emailid (Emailid decides Student#)

50. Student# Course# (decides rest of the attributes in Result table)

51. Course# Emailid (decides rest of the attributes in Result table)All above determinants are not candidate keys. Emailid decides Student# but Emailid on its own is not a candidate key. Similarly Student# decides Emailid of a student but Student# alone is not a candidate key. Only combination of Student# Course# and Course# Emailid are candidate keys. To make this table BCNF, we need to split this table into the following structure: Fourth Normal Form (4 NF) Finally, fourth normal form has one additional requirement: Meet all the requirement of the third normal form.

52. A relation is in 4NF if it has no multi-valued dependencies.Explanation with Example Let's say we want to create a table of user information, and we want to store each users' Name, Company, Company Address, and some personal bookmarks, or urls. You might start by defining a table structure like this: Zero Form usersNamecompanycompany_addressurl1url2JoeABC1 Work Laneabc.comxyz.comJillXYZ1 Job Streetabc.comxyz.com We would say this table is in Zero Form because none of our rules of normalization have been applied yet. Notice the url1 and url2 fields -- what do we do when our application needs to ask for a third url? Do you want to keep adding columns to your table and hard-coding that form input field into your HTML code? Obviously not, you would want to create a functional system that could grow with new development requirements. Let's look at the rules for the First Normal Form, and then apply them to this table. First Normal Form Eliminate repeating groups in individual tables.

53. Create a separate table for each set of related data.

54. Identify each set of related data with a primary key.Notice how we're breaking that first rule by repeating the url1 and url2 fields? And what about Rule Three, primary keys? Rule Three basically means we want to put some form of unique, auto-incrementing integer value into every one of our records. Otherwise, what would happen if we had two users named Joe and we wanted to tell them apart? When we apply the rules of the First Normal Form we come up with the following table: usersuserIdnamecompanycompany_addressurl1JoeABC1 Work Laneabc.com1JoeABC1 Work Lanexyz.com2JillXYZ1 Job Streetabc.com2JillXYZ1 Job Streetxyz.com [ Now our table is said to be in the First Normal Form. We've solved the problem of url field limitation, but look at the headache we've now caused ourselves. Every time we input a new record into the users table, we've got to duplicate all that company and user name data. Not only will our database grow much larger than we'd ever want it to, but we could easily begin corrupting our data by misspelling some of that redundant information. Let's apply the rules of Second Normal Form: Second Normal Form Create separate tables for sets of values that apply to multiple records.

55. Relate these tables with a foreign key.We break the url values into a separate table so we can add more in the future without having to duplicate data. We'll also want to use our primary key value to relate these fields: usersuserIdnamecompanycompany_address1JoeABC1 Work Lane2JillXYZ1 Job Street urlsurlIdrelUserIdurl11abc.com21xyz.com32abc.com42xyz.com Ok, we've created separate tables and the primary key in the users table, userId, is now related to the foreign key in the urls table, relUserId. We're in much better shape. But what happens when we want to add another employee of company ABC? Or 200 employees? Now we've got company names and addresses duplicating themselves all over the place, a situation just rife for introducing errors into our data. So we'll want to look at applying the Third Normal Form: Third Normal Form Eliminate fields that do not depend on the key.Our Company Name and Address have nothing to do with the User Id, so they should have their own Company Id: usersuserIdnamerelCompId1Joe12Jill2 urlsurlIdrelUserIdurl11abc.com21xyz.com32abc.com42xyz.com Now we've got the primary key compId in the companies table related to the foreign key in the users table called relCompId, and we can add 200 users while still only inserting the name \" ABC\" once. Our users and urls tables can grow as large as they want without unnecessary duplication or corruption of data. Most developers will say the Third Normal Form is far enough, and our data schema could easily handle the load of an entire enterprise, and in most cases they would be correct. But look at our url fields - do you notice the duplication of data? This is perfectly acceptable if we are not pre-defining these fields. If the HTML input page which our users are filling out to input this data allows a free-form text input there's nothing we can do about this, and it's just a coincidence that Joe and Jill both input the same bookmarks. But what if it's a drop-down menu which we know only allows those two urls, or maybe 20 or even more. We can take our database schema to the next level, the Fourth Form, one which many developers overlook because it depends on a very specific type of relationship, the many-to-many relationship, which we have not yet encountered in our application. companiescompIdcompanycompany_address1ABC1 Work Lane2XYZ1 Job Street Data Relationships Before we define the Fourth Normal Form, let's look at the three basic data relationships: one-to-one, one-to-many, and many-to-many. Look at the users table in the First Normal Form example above. For a moment let's imagine we put the url fields in a separate table, and every time we input one record into the users table we would input one row into the urls table. We would then have a one-to-one relationship: each row in the users table would have exactly one corresponding row in the urls table. For the purposes of our application this would neither be useful nor normalized. Now look at the tables in the Second Normal Form example. Our tables allow one user to have many urls associated with his user record. This is a one-to-many relationship, the most common type, and until we reached the dilemma presented in the Third Normal Form, the only kind we needed. The many-to-many relationship, however, is slightly more complex. Notice in our Third Normal Form example we have one user related to many urls. As mentioned, we want to change that structure to allow many users to be related to many urls, and thus we want a many-to-many relationship. Let's take a look at what that would do to our table structure before we discuss it: usersuserIdnamerelCompId1Joe12Jill2 companiescompIdcompanycompany_address1ABC1 Work Lane2XYZ1 Job Street urlsurlIdurl1abc.com2xyz.com url_relationsrelationIdrelatedUrlIdrelatedUserId111212321422 In order to decrease the duplication of data (and in the process bring ourselves to the Fourth Form of Normalization), we've created a table full of nothing but primary and foreign keys in url_relations. We've been able to remove the duplicate entries in the urls table by creating the url_relations table. We can now accurately express the relationship that both Joe and Jill are related to each one of, and both of, the urls. So let's see exactly what the Fourth Form of Normalization entails: Fourth Normal Form In a many-to-many relationship, independent entities cannot be stored in the same table.Since it only applies to the many-to-many relationship, most developers can rightfully ignore this rule. But it does come in handy in certain situations, such as this one. We've successfully streamlined our urls table to remove duplicate entries and moved the relationships into their own table. Just to give you a practical example, now we can select all of Joe's urls by performing the following SQL call: SELECT name, url FROM users, urls, url_relations WHERE url_relations.relatedUserId = 1 AND users.userId = 1 AND urls.urlId = url_relations.relatedUrlId And if we wanted to loop through everybody's User and Url information, we'd do something like this: SELECT name, url FROM users, urls, url_relations WHERE users.userId = url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId What is the difference between a “where” clause and a “having” clause? “Where” is a restriction statement? You use where clause to restrict data being accessed from the database. Where clause is used before result is retrieved. But having clause is used after retrieving the data. Having clause is a kind of filtering command. What is de-normalization and when do we use De-normalization? De-normalization is a technique to move from higher normal form to lower normal form in order to speed up database access. De-normalization is done when fast retrieval is must than redundancy. SQL Statements: StatementSyntaxAND / ORSELECT column_name(s)FROM table_nameWHERE conditionAND|OR conditionALTER TABLEALTER TABLE table_name ADD column_name datatypeorALTER TABLE table_name DROP COLUMN column_nameAS (alias)SELECT column_name AS column_aliasFROM table_nameorSELECT column_nameFROM table_name AS table_aliasBETWEENSELECT column_name(s)FROM table_nameWHERE column_nameBETWEEN value1 AND value2CREATE DATABASECREATE DATABASE database_nameCREATE TABLECREATE TABLE table_name(column_name1 data_type,column_name2 data_type,column_name2 data_type,...)CREATE INDEXCREATE INDEX index_nameON table_name (column_name)orCREATE UNIQUE INDEX index_nameON table_name (column_name)CREATE VIEWCREATE VIEW view_name ASSELECT column_name(s)FROM table_nameWHERE conditionDELETEDELETE FROM table_nameWHERE some_column=some_valueorDELETE FROM table_name (Note: Deletes the entire table!!)DELETE * FROM table_name (Note: Deletes the entire table!!)DROP DATABASEDROP DATABASE database_nameDROP INDEXDROP INDEX table_name.index_name (SQL Server)DROP INDEX index_name ON table_name (MS Access)DROP INDEX index_name (DB2/Oracle)ALTER TABLE table_nameDROP INDEX index_name (MySQL)DROP TABLEDROP TABLE table_nameGROUP BYSELECT column_name, aggregate_function(column_name)FROM table_nameWHERE column_name operator valueGROUP BY column_nameHAVINGSELECT column_name, aggregate_function(column_name)FROM table_nameWHERE column_name operator valueGROUP BY column_nameHAVING aggregate_function(column_name) operator valueINSELECT column_name(s)FROM table_nameWHERE column_nameIN (value1,value2,..)INSERT INTOINSERT INTO table_nameVALUES (value1, value2, value3,....)orINSERT INTO table_name(column1, column2, column3,...)VALUES (value1, value2, value3,....)INNER JOINSELECT column_name(s)FROM table_name1INNER JOIN table_name2 ON table_name1.column_name=table_name2.column_nameLEFT JOINSELECT column_name(s)FROM table_name1LEFT JOIN table_name2 ON table_name1.column_name=table_name2.column_nameRIGHT JOINSELECT column_name(s)FROM table_name1RIGHT JOIN table_name2 ON table_name1.column_name=table_name2.column_nameFULL JOINSELECT column_name(s)FROM table_name1FULL JOIN table_name2 ON table_name1.column_name=table_name2.column_nameLIKESELECT column_name(s)FROM table_nameWHERE column_name LIKE patternORDER BYSELECT column_name(s)FROM table_nameORDER BY column_name [ASC|DESC]SELECTSELECT column_name(s)FROM table_nameSELECT *SELECT *FROM table_nameSELECT DISTINCTSELECT DISTINCT column_name(s)FROM table_nameSELECT INTOSELECT *INTO new_table_name [IN externaldatabase]FROM old_table_nameorSELECT column_name(s)INTO new_table_name [IN externaldatabase]FROM old_table_nameSELECT TOPSELECT TOP number|percent column_name(s)FROM table_nameTRUNCATE TABLETRUNCATE TABLE table_nameUNIONSELECT column_name(s) FROM table_name1UNIONSELECT column_name(s) FROM table_name2UNION ALLSELECT column_name(s) FROM table_name1UNION ALLSELECT column_name(s) FROM table_name2UPDATEUPDATE table_nameSET column1=value, column2=value,...WHERE some_column=some_valueWHERESELECT column_name(s)FROM table_nameWHERE column_name operator value

Database Concepts

Recommended

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Database Concepts (20)

Recently uploaded (20)

Database Concepts