Your SlideShare is downloading. ×
0
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Database design
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Database design

127

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
127
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Database Design Database design process can be broken down into 5 phases • Planning • Analysis • Design • Implementation • Maintenance
  • 2. Planning Phase In planning phase the overall Database structure is defined. Therefore; • The purpose of the database is determined – What information will be used in the Database – How information is to be used – What question will be Answered • Feasibility studies are conducted. • Requirements gathering
  • 3. Analysis phase Databases can be analyzed on different models • Conceptual-model – High-level description of facts – Not system specific • Logical model – Organization of data with some implementation information • Physical model – Actual storage of information (clustering, partitioning, indexing etc.)
  • 4. Conceptual model • Provide a framework for developing a database structure. • Three database components (entities, attributes and relationship) are described in detail.
  • 5. Entities • An entity defines a thing that exists and is distinguishable. i.e Person, place, object or concept. • Entities are basic building blocks of the database design. • particular occurrence of an entity is known as entity instance. • A group of similar entities is called entity set or entity class
  • 6. Attributes Attributes describe properties of entities and relationships • Simple (Scalars) - smallest semantic unit of data, atomic (no internal structure)- singular e.g. city • Composite - group of attributes e.g. address (street, city, state, zip) • Multivalued (list) - multiple values e.g. degrees, courses, skills (not allowed in first normal form) • Domain - conceptual definition of attributes – a named set of scalar values all of the same type e.g. integer a pool of possible values
  • 7. Relationships A relationship is a connection between entity classes. For example, a relationship between PERSONS and AUTOMOBILES could be an "OWNS" relationship. That is to say, people own automobiles. • The degree of a relationship indicates the number of entities involved. • The cardinality of a relationship indicates the number of instances in entity class E1 that can or must be associated with instances in entity class E2
  • 8. Types of Relationship Based on cardinality of a relationship, we have 3 types: - • One-One Relationship - For each entity in one class there is at most one associated entity in the other class. For example, for each husband there is at most one current legal wife (in this country at least). A wife has at most one current legal husband. • Many-One Relationships - One entity in class E2 is associated with zero or more entities in class E1, but each entity in E1 is associated with at most one entity in E2. For example, a woman may have many children but a child has only one birth mother. • Many-Many Relationships - There are no restrictions on how many entities in either class are associated with a single entity in the other. An example of a many-to-many relationship would be students taking classes. Each student takes many classes. Each class has many students.
  • 9. Logical model • After validating your conceptual mode, you can generate a logical model – Entity Classes are modeled as tables – Attributes are modeled as fields – Each instance of an entity is called a record – Domain are modeled as Data types – Primary keys for each table – Foreign keys for relationship
  • 10. Physical –model • How data will be stored and accessed in a computer system. • Where data will be stored • Estimate the amount of disk space that will be required by the database. • How data will be distributed within an organization or disks • type of indexes to be used (for efficient retrieval and manipulation).
  • 11. Design Phase Determine how best to represent the information system that was identified in the previous phase Mapping Logical Model and physical model into reality. – Database Management system (DBMS) to be used. – User Views (input forms, output reports) – Security Mechanisms etc.
  • 12. Implementation phase Actual implementation of the database and associated programming. • Database is analyzed for possible errors • Tables are created with few records for sample to see if the desired results are achieved • Fine adjustments as needed
  • 13. Entity Relationship Model • Conceptual data model that views the real world as entities and relationships. • A basic component of the model is the Entity-Relationship diagrams (ERDs), • (ERDs) provides a convenient method for visualizing the interrelationships among entities in a given application
  • 14. The utility of the ER model is: • It maps well to the relational database model.. • It is simple and easy to understand with a minimum of training. • the model can be used as a design plan by the database developer to implement a data model in specific database management software.
  • 15. Basic Elements in E-R Modeling The basic elements in ER modal are • entities • attributes and • Relationships.
  • 16. Entities • Data object about which information is to be collected. • Some specific examples of entities are EMPLOYEE, PROJECT, INVOICE. • An entity occurrence (also called an instance) is an individual occurrence of an entity. • Entity set: a collection of similar entities (employees, projects, departments)
  • 17. Attributes • describe the entity of which they are associated. • A particular instance of an attribute is a value. • Attributes can be classified as identifiers or descriptors. • Identifiers, more commonly called keys, uniquely identify an instance of an entity. • A descriptor describes a non-unique characteristic of an entity instance.
  • 18. Relationships • Represents an association between two or more entities. An example of a relationship would be: employees are assigned to projects projects have subtasks departments manage one or more projects • Relationships are classified in terms of – degree, – connectivity, – cardinality, – and existence.
  • 19. Classifying Relationships Degree of a Relationship • number of entities associated with the relationship.  A UNARY RELATIONSHIP exists when an association exists within a single entity  A BINARY RELATIONSHIP exists when two entities(participants) are in the relationship.  A TERNARY RELATIONSHIP exists when three entities (participants) are in the relationship.
  • 20. Classifying Relationships The connectivity – describes the mapping of associated entity instances in the relationship. – The values of connectivity are "one" or "many". – The basic types of connectivity for relations are: one-to-one, one-to-many, and many-to-many. The cardinality – actual number of related occurrences for each of the two entities.
  • 21. Classifying Relationships Existence • denotes whether the existence of an entity instance is dependent upon the existence of another, related, entity instance. • Defined as either mandatory or optional. – For mandatory existence an instance of an entity must always occur. "every project must be managed by a single department". – For optional existence the instance of the entity is not required or may occur
  • 22. ER Notation • There is no universal standard for representing data objects in ER diagrams. • Number of Notation styles is used today, among the more common are information Engineering, Bachman, Chen and Martin.
  • 23. ER Notation Martin Style. • Entities are represented by labeled rectangles. The label is the name of the entity. Entity names should be singular nouns. • Relationships are represented by a solid line connecting two entities. The name of the relationship is written above the line. Relationship names should be verbs. • Attributes, when included, are listed inside the entity rectangle. Identifier Attributes are underlined. Attribute names should be singular nouns. • Cardinality of many is represented by a line ending in a crow's foot. If the crow's foot is omitted, the cardinality is one. • Existence is represented by placing a circle or a perpendicular bar on the line. Placing a bar line next to the entity shows mandatory existence. Placing a circle next to the entity shows optional existence.
  • 24. Martin Style.
  • 25. ER Notation Chen Style • Rectangles represent ENTITY CLASSES • Circles represent ATTRIBUTES • Diamonds represent RELATIONSHIPS • Lines - lines connect entities to relationships. Lines are also used to connect attributes to entities. • Underline - Key attributes of entities are underlined. • Number Notations represents cardinality. • The name of the entity (class) or attribute or relationship is usually placed inside the symbol used for that object. (Sometimes, the name is placed adjacent.) •
  • 26. Chen Style
  • 27. Refining The Entity-Relationship Diagram This section discusses four basic rules for modeling relationships 1. Entities Must Participate In Relationships – Entities cannot be modeled unrelated to any other entity. – The exception to this rule is a database with a single table.
  • 28. Refining The Entity-Relationship Diagram 2. Resolve Many-To-Many Relationships – Many-to-many relationships cannot be used in the data model because they cannot be represented by the relational model. – must be resolved early in the modeling process. – replace the relationship with an association entity and then relate the two original entities to the association entity
  • 29. This strategy is demonstrated below Figure below: - Here Employees may be assigned to many projects. Each project must have assigned to it more than one employee.
  • 30. Refining The Entity-Relationship Diagram 3. Transform Complex Relationships into Binary Relationships • Complex relationships are classified as ternary, an association among three entities, or n-ary, an association among more than three, where n is the number of entities involved. • cannot be directly implemented in the relational model. • so they should be resolved early in the modeling process. • The strategy for resolving complex relationships is similar to resolving many-to-many relationships. • Replace the complex relationship with an association entity and then relate the two original entities to the association entity
  • 31. Here is an example Employees can use different skills on any one or more projects. Each project uses many employees with various skills.
  • 32. Refining The Entity-Relationship Diagram 4. Eliminate redundant relationships – A redundant relationship is a relationship between two entities that is equivalent in meaning to another relationship between those same two entities.
  • 33. For example, Figure A shows a redundant relationship between DEPARTMENT and WORKSTATION. This relationship provides the same information as the relationships DEPARTMENT has EMPLOYEES and EMPLOYEEs assigned WORKSTATION. Figure B shows the solution which is to remove the redundant relationship DEPARTMENT assigned WORKSTATIONS.
  • 34. Tips for Effective ER Diagrams • Make sure that each entity only appears once per diagram. • Name every entity, relationship, and attribute on your diagram. • Examine relationships between entities closely. Are they necessary? Are their any relationships missing? Eliminate any redundant relationships. Don't connect relationships to each other. • Use colors to highlight important portions of your diagram
  • 35. Normalization • Normalization is the process of refining a database design to produce table schemes in normal form. • A normal form refers to a class of relational schemas that obey some set of rules. • Schemas that obey the rules are said to be in the normal form. • Non–normal form is where data may recur repetitively. • Normalization is aiming at minimizing redundancy in database
  • 36. Classifying normal forms • There are six commonly recognized normal forms, with the inspired names: – First normal form (or 1NF) – Second normal form (or 2NF) – Third normal form (or 3NF) – Boyce-Codd normal form (or BCNF) – Fourth normal form (or 4NF) – Fifth normal form (or 5NF) • We will consider the first three of these normal forms
  • 37. First normal form (or 1NF) A relation is in First Normal Form (1NF) if every attribute value is indivisible (atomic) and every column is unique. • First normal form (1NF) sets the very basic rules for an organized database: – Eliminate duplicative columns from the same table. – Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key).
  • 38. Second normal form (or 2NF) A relation is in Second Normal Form (2NF) if it is in 1NF and if all of its attributes are dependent on the whole key (i.e. none of the non-key attributes are related only to a part of the key). • Second normal form (2NF) further addresses the concept of removing duplicative data: – Remove subsets of data that apply to multiple rows of a table and place them in separate tables. •     Create relationships between these new tables and their predecessors through the use of foreign keys.
  • 39. Third normal form (or 3NF) A relation is in Third Normal Form (3NF) if it is in 2NF and there are no transitive dependencies (i.e. none of the non-key attributes are dependent upon another attribute which in turn is dependent on the relation key). • Third normal form (3NF) goes one large step further: Remove columns that are not dependent upon the primary key.
  • 40. Fourth normal form (or 4NF) • A relation is in 4NF if it has no multi-valued dependencies.

×