Professional Documents
Culture Documents
Data Processing Basic DBMS concepts Basic RDBMS concepts Conceptual Database Design ER Modeling Notations
Data collection Recording Sorting Classifying Calculating Storing & retrieving Summarizing Communicating
Batch processing: Transactions are collected in a group & processed together. On-line (interactive) processing: Transactions are processed as & when they appear. Real-time processing: It is a parallel time relationship with on-going activity & the information produced is useful in controlling the current/dynamic activity.
A DBMS has to be persistent, that is it should be accessible when the program created the data ceases to exist or even when the application that created the data restarted. A DBMS also has to provide some uniform methods independent of a specific application for accessing the information that is stored. RDBMS is a Relational Data Base Management System (Relational DBMS). This adds the additional condition that the system supports a tabular structure for the data, with enforced relationships between the tables. This excludes the databases that don't support a tabular structure or don't enforce relationships between tables.
Data is viewed as existing in two dimensional tables known as relations An entity (table) consists of unique attributes (columns) and tuples (rows) Tuples are unique Sometimes the value to be inserted into a particular cell may be unknown, or it may have no value. This is represented by a null Null is not the same as zero, blank or an empty string Relational Database: Any database whose logical organization is based on relational data model. RDBMS: A DBMS that manages the relational database.
Entity type Attribute Multivalued attribute Relationship Degree Cardinality Business Rule Associative entity
Learn to draw Entity-Relationship (E-R) Diagrams Review the role of conceptual data modeling in overall design and analysis of an information system Distinguish between unary, binary, and ternary relationships, and give an example of each Define four basic types of business rules in an E-R diagram
Representation of organizational data Purpose is to show rules about the meaning and interrelationships among entities Entity-Relationship (E-R) diagrams are commonly used to show how data are organized Main goal of conceptual data modeling is to create accurate E-R diagrams Methods such as interviewing, questionnaires and JAD are used to collect information Consistency must be maintained between process flow, decision logic and data modeling descriptions
First step is to develop a data model for the system being replaced Next, a new conceptual data model is built that includes all the requirements of the new system In the design stage, the conceptual data model is translated into a physical design Project repository links all design and data modeling steps performed during SDLC
Primary deliverable is the entity-relationship diagram There may be as many as 4 E-R diagrams produced and analyzed during conceptual data modeling
Covers just data needed in the projects application E-R diagram for system being replaced An E-R diagram for the whole database from which the new applications data are extracted An E-R diagram for the whole database from which data for the application system being replaced is drawn
Two perspectives
Top-down
Data model is derived from an intimate understanding
of the business
Bottom-up
Data model is derived by reviewing specifications and
business documents
Entity
A person, place, object, event or concept in the user environment about which the organization wishes to maintain data Represented by a rectangle in E-R diagrams
A collection of entities that share common properties or characteristics A named property or characteristic of an entity that is of interest to an organization
Attribute
Usually a noun in singular Represented by a rectangle with a label First letter in capitals
Simple attribute: cannot be divided into simpler components E.g birthdate of an employee Composite attribute: can be split into components E.g Address of the employee.
Single valued : can take on only a single value for each entity instance E.g. birth date of employee. There can be only one value for this Multi-valued: can take many values E.g. skill set of employee like MATLAB,.net developer programming,etc
Stored Attribute: Attribute that need to be stored permanently. E.g. name of an employee Derived Attribute: Attribute that can be calculated based on other attributes. E.g. : years of service of employee can be calculated from date of joining and current date
Regular Entity: Entity that has its own key attribute. E.g.: Employee, student ,customer, policy holder etc. Weak entity: Entity that depends on other entity for its existence and doesnt have key attribute of its own E.g. : spouse of employee
A relationship type between two entity types defines the set of all associations between these entity types Each instance of the relationship between members of these entity types is called a relationship instance
Primary Key Unique Key Composite Key Foreign Key Surrogate Key Candidate Key Alternate Key
Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type
Attribute (or combination of attributes) that uniquely identifies each instance of an entity type
Candidate key
Identifier
A candidate key that has been selected as the unique identifying characteristic for an entity type
Multi-valued Attribute
An attribute that may take on more than one value for each entity instance Represented on E-R Diagram in two ways:
double-lined ellipse weak entity
Relationship
An association between the instances of one or more entity types that is of interest to the organization Association indicates that an event has occurred or that there is a natural link between entity types Relationships are always labeled with verb phrases
Degree
Three cases
Binary
A relationship between the instances of two entity types
Ternary
A simultaneous relationship among the instances of three
The number of instances of entity B that can be associated with each instance of entity A Minimum Cardinality
The minimum number of instances of entity B that may be associated with each instance of entity A The maximum number of instances of entity B that may be associated with each instance of entity A
Maximum Cardinality
Relationship name is a verb phrase Avoid vague names Guidelines for defining relationships
Definition explains what action is being taken and why it is important Give examples to clarify the action Optional participation should be explained Explain reasons for any explicit maximum cardinality
All instances of the entity type Employee dont participate in the relationship, Head-of. Every employee doesnt head a department. So, employee entity type is said to partially participate in the relationship. But, every department would be headed by some employee. So, all instances of the entity type Department participate in this relationship. So, we say that it is total participation from the department side.
The set of all data types and ranges of values that an attribute can assume Several advantages
1. Verify that the values for an attribute are valid 2. Ensure that various data manipulation operations are logical 3. Help conserve effort in describing attribute characteristics
Banks have customers. Customers are identified by name, custid, phone number and address. Customers can have one or more accounts Accounts are identified by an account number, account type (savings, current) and a balance. Customers can avail loans. Loans are identified by loan id, loan type (car, home, personal) and an amount. Banks are identified by a name, code and the address of the main office. Banks have branches. Branches are identified by a branch number, branch name and an address. Accounts and loans are related to the banks branches.
Each entity type becomes a table Each single-valued attribute becomes a column Derived attributes are ignored Composite attributes are represented by components Multi-valued attributes are represented by a separate table The key attribute of the entity type becomes the primary key of the table
Here address is a composite attribute Years of service is a derived attribute (can be calculated from date of joining and current date) Skill set is a multi-valued attribute The relational Schema Employee (E#, Name, Door_No, Street, City, Pincode, Date_Of_Joining) Emp_Skillset( E#, Skill)
Weak entity types are converted into a table of their own, with the primary key of the strong entity acting as a foreign key in the table This foreign key along with the key of the weak entity form the composite primary key of this table The Relational Schema
The way relationships are represented depends on the cardinality and the degree of the relationship The possible cardinalities are:
Consider employees who are also a couple The primary key field itself will become foreign key in the same table
The primary key field itself will become foreign key in the same table Same as unary 1:1
There will be two resulting tables. One to represent the entity and another to represent the M:N relationship as follows
The primary key of the partial participant will become the foreign key of the total participant
The primary key of either of the participants can become a foreign key in the other
The primary key of the relation on the 1 side of the relationship becomes a foreign key in the relation on the N side
A new table is created to represent the relationship Contains two foreign keys - one from each of the participants in the relationship The primary key of the new table is the combination of the two foreign keys
An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances
Well-structured table - contains minimal redundancy and allows users to insert, modify, and delete the rows without errors or inconsistencies. The possible anomalies could be
The formal process that can be followed to achieve a good database design Also used to check that an existing design is of good quality The different stages of normalization are known as normal forms
An attribute B of a relation R is fully functionally dependent on attribute A of R if it is functionally dependent on A & not functionally dependent on any proper subset of A.
An attribute B of a relation R is partially dependent on attribute A of R if it is functionally dependent on any proper subset of A.
An attribute B of a relation R is transitively dependent on attribute A of R if it is functionally dependent on an attribute C Which in turn is functionally dependent on A or any proper subset of A. S
An attribute of a relation R that belongs to any key of R is said to be a prime attribute and that which doesnt is a non-prime attribute
A relation schema R is in 2NF if it is in 1NF and every non-prime attribute is fully functionally dependent on every key of R Consider the relational schema:
In this,
E#, Project# -> Role E# -> Number_Of_shares
Number_of_Shares, Share_Worth
A relation schema R is in 3NF if it is in 2NF and every non-prime attribute is non-transitively dependent on every key of R
A relation R is in BCNF if, for every non-trivial functional dependency A->B in it, it is true that A is a superkey of R In other words, every determinant is a candidate key BCNF is a stronger form of 3NF 3NF states that every non-prime attribute must be non-transitively dependent on every key BCNF states that every attribute (prime or nonprime) must be non-transitively dependent on every key
In the table, the only non-prime attribute is Num-of_students. It depends on every key of the table nontransitively So, it is in 3NF But, the fact that Lecturer L1 belongs to department D1 is repeated redundancy Lecturer#->Dept#. In this, the attribute Dept# is only partially dependent on the key
A caterers association in a city wants to build a database of all the caterers who are members of the association. Every type of item has got an item code for example:
Idly - itemcode : bf1 dosa - itemcode : bf2 aloo paratha itemcode : bf 3 south indian meals itemcode : ln1
Each caterer may have outlets spread over the city. It is not necessary that all caterers or all branches of a single caterer must provide all item types. Design the relational schema for the above requirement. Normalize the relations.