Recomendados
Más contenido relacionado
Similar a Week 2 - Database System Development Lifecycle-old.pptx
Similar a Week 2 - Database System Development Lifecycle-old.pptx (20)
Último
Último (20)
Week 2 - Database System Development Lifecycle-old.pptx
- 1. BITG 2323: WEEK 2 Database System Development Lifecycle (SDLC) • Information and database system development lifecycle (DbLC) • Relational Data model
- 2. Database System Development Lifecycle
- 3. The System Design Life Cycle (SDLC) illustrates the life cycle of an information system. It is the overall or big picture of what has and what will historically happen to the system. The Database Life Cycle (DBLC) likewise exhibits the life cycle of a database within an information system. SDLC & DbLC Information & Db System Lifecycle Introduction
- 5. DbLC Information & Db System Lifecycle Phases Initial Study Design Implement & Loading Test & Evaluate Operation Maintenance & Evaluation
- 6. SDLC & DbLC Information & Db System Lifecycle Parallel Activities
- 7. SDLC & DbLC Information & Db System Lifecycle Parallel Activities
- 8. Training Technology Company Overall current system description The administrator accepts job applicants, types their CVs and files it in applicants file. Administrator goes through TEMP- STAFF files, collecting relevant information about temporary instructor’s class and time table.The company also compiles reports on instructors based on feedback information received from students. Every end of course session, these instructors will hand in students marks and their time sheets to the administrator in order to get their pay. There are no formal methods of documenting the temporary instructors’ performance in the various placements made by the company. The reports received were usually informal comments received over a phone and were not systematically recorded. DbLC Information & Db System Lifecycle Initial Study Problem and Constraints Initial Study • Analyse company situation • Define problems & constraints • Define objective • Define scope & boundaries
- 9. DbLC Information & Db System Lifecycle Initial Study Initial Study • Analyse company situation • Define problems & constraints • Define objective • Define scope & boundaries
- 10. Training Technology Company 1. Automated business system 2. Manage and track : • class registration • class schedule • instructor availability mission DbLC Information & Db System Lifecycle Initial Study Initial Study • Analyse company situation • Define problems & constraints • Define objective • Define scope & boundaries
- 11. • How does the existing system function? • What input does the system require? • What documents does the system generate? • How is the system output used? By Whom? • What are the operational relationships among business units? • What are the limits and constraints imposed on the system? DbLC Information & Db System Lifecycle Initial Study Initial Study • Analyse company situation • Define problems & constraints • Define objective • Define scope & boundaries
- 12. Define Objective from manual to Auto user able to access database instructor able to query and make changes to data student able to query online Initial Study • Analyse company situation • Define problems & constraints • Define objective • Define scope & boundaries DbLC Information & Db System Lifecycle Initial Study
- 13. Scope and Boundaries How big is the system required? Budget Hardware and Software Requirement Organizational change / extent Must correspond to those envisioned by end users • What is proposed system’s initial objective? • Will system interface with other systems in the company? • Will system share data with other systems or users? Database System Objectives Initial Study • Analyse company situation • Define problems & constraints • Define objective • Define scope & boundaries DbLC Information & Db System Lifecycle Initial Study
- 14. DbLC Information & Db System Lifecycle Design Design • Create conceptual design • DBMS software selection • Create logical design • Create physical design
- 15. DbLC Information & Db System Lifecycle Database Design Process Conceptual Logical Physical DBMS Selection • Data analysis and requirements • Entity relationship modeling and normalization • Data model verification • Distributed database design • Define tables, columns, relationships & constraints • Normalized set of tables • Ensure entity and referential integrity; define column constraints • Ensure the model supports user requirements • Common factors affecting purchasing decisions: – Cost (Purchase, maintenance, operational, license, installation, training, and conversion costs.) – DBMS features and tools (report generators etc.) – Underlying model (Relational/OO) – Portability (Platforms, systems, and languages) – DBMS hardware requirements •Process of selecting the data storage and data access characteristics of the database (integrity and security measures). •It affects not only the location of the data in the storage device(s) but also the performance : e.g. – Storage media – Seek time Design • Create conceptual design • DBMS software selection • Create logical design • Create physical design
- 16. DbLC Information & Db System Lifecycle Implementation and Loading • Implement all design specifications from previous phase: –Install the DBMS •V creates logical representations of computing resources independent of physical resources –Create the Database –Load or Convert the Data Implementation and Loading • Install DBMS • Create databases • Load or convert data
- 17. DbLC Information & Db System Lifecycle Testing and Evaluation •Occurs in parallel with applications programming •If implementation fails to meet some of system’s evaluation criteria: –Fine-tune specific system and DBMS configuration parameters –Modify physical or logical design –Upgrade software and/or hardware platform •Integrity –Enforced via proper use of primary, foreign key rules •Backup and Recovery –Full backup –Differential backup –Transaction log backup Testing and Evaluation • Test database • Fine-tune database • Evaluate database and its apps.
- 18. • Once database has passed evaluation stage, it is considered operational • Beginning of operational phase starts process of system evolution • Problems not foreseen during testing surface • Solutions may include: –Load-balancing software to distribute transactions among multiple computers –Increasing available cache DbLC Information & Db System Lifecycle Operation Operation • Produce the required information flow
- 19. DbLC Information & Db System Lifecycle Maintenance and Evaluation • Required periodic maintenance: –Preventive maintenance (backup) –Corrective maintenance (recovery) –Adaptive maintenance –Assignment of access permissions and their maintenance for new and old users –Generation of database access statistics –Periodic security audits –Periodic system-usage summaries Maintenance and Evolution • Introduce changes • Make enhancements
- 20. • Information system facilitates transformation of data into information – Manages both data and information • SDLC traces history (life cycle) of an application within the information system • DBLC describes history of database within the information system • Database design and implementation process moves through series of well-defined stages SUMMARY
- 22. • Relational model –View data logically rather than physically • Table –Structural and data independence –Resembles a file conceptually • Relational database model is easier to understand than hierarchical and network models Relational Database Model Relational Database Model A Logical View of Data
- 23. Relational Database Model Tables and Their Characteristics • Logical view of relational database is based on relation –Relation thought of as a table • Table: two-dimensional structure composed of rows and columns • Contains group of related entities (entity set) Relational Database Model
- 25. Keys Types • Each row in a table must be uniquely identifiable • Key: one or more attributes that determine other attributes –Key’s role is based on determination •If you know the value of attribute A, you can determine the value of attribute B –Functional dependence •Attribute B is functionally dependent on A if all rows in table that agree in value for A also agree in value for B Relational Database Model
- 26. • Entity integrity – Each row (entity instance) in the table has its own unique identity • Nulls – No data entry – Not permitted in primary key – Should be avoided in other attributes • Controlled redundancy – Makes the relational database work – Tables within the database share common attributes •Enables tables to be linked together – Multiple occurrences of values not redundant when required to make the relationship work – Redundancy exists only when there is unnecessary duplication of attribute values Keys Types Relational Database Model
- 27. SUPERKEY CANDIDATE PRIMARY FOREIGN COMPOSITE A Super key is any combination of fields within a table that uniquely identifies each record within that table. it is an attribute or set of attribute that can be selected as primary key for a table to uniquely identify each record in that table is a candidate key that is most appropriate to become main key to uniquely identify each record in a table key that consist two or more attributes that uniquely identify an entity assurance A foreign key is generally a primary key from one table that appears as a field in another where the first table has a relationship to the second. Keys Types Relational Database Model
- 28. Consider a Relation or Table R1. Let A,B,C,D,E are the attributes of this relation. A→B,C,D,E This means the attribute 'A' uniquely determines the other attributes B,C,D,E. B,C→A,D,E This means the attributes 'BC' jointly determines all the other attributes A,D,E in the relation. Primary Key : A Candidate Keys : A, BC Super Keys : A,BC,ABC,AD Keys Types - Example Relational Database Model R(A,B,C,D,E)
- 29. SUPERKEY CANDIDATE PRIMARY FOREIGN COMPOSITE First Name Last Name gender ZULAIKHA AFFENDI F ZULAIKHA AFFENDI F Keys Types Relational Database Model There are two people with same name! Which one is which? A Super key is any combination of fields within a table that uniquely identifies each record within that table. For example, the super key can be a combination of a name, phone number, address and b.o.d This would always be unique unless 2 people with the same name lived in the same place with the same phone number
- 30. SUPERKEY CANDIDATE PRIMARY FOREIGN COMPOSITE First Name Last Name gender SSN phone number Keys Types Relational Database Model Candidate key is a partial of the super key. If super key is already the least amount of columns then, both the superkey and the candidate key will be the same thing. Candidate key Superkey
- 31. SUPERKEY CANDIDATE PRIMARY FOREIGN COMPOSITE s_id s_name age course address Primary Key cust_id order_id sale_detail Composite Key Keys Types Relational Database Model
- 32. NULL VALUE • Many RDBMs enforce integrity rules automatically • Safer to ensure that application design conforms to entity and referential integrity rules • Designers use flags to avoid nulls – Flags indicate absence of some value Integrity Rules Relational Database Model
- 33. The Data Dictionary and System Catalog • Data dictionary – Provides detailed accounting of all tables found within the user/designer-created database – Contains (at least) all the attribute names and characteristics for each table in the system – Contains metadata: data about data • System catalog – Contains metadata – Detailed system data dictionary that describes all objects within the database Relational Database Model
- 34. Relationship Types 1:M 1:1 M:N • One entity related to only one other entity, and vice versa • Sometimes means that entity components were not defined properly • Could indicate that two entities actually belong in the same table • Certain conditions absolutely require • Cannot be implemented as such in the relational model • M:N relationships can be changed into 1:M relationships • Relational modeling ideal • Should be the norm in any relational database design Relational Database Model
- 35. Relationship Types An(one) Author writes many Books A Student leads many student …………. ….. Relational Database Model
- 37. Data Redundancy •It is crucial •When data stored is not consistant •A well design of DBMS can help to reduce data redundancy •Errors more likely to occur when complex data entries are made in several different files •Error also occur if data recur frequently in one or more files • Data redundancy leads to data anomalies – Can destroy the effectiveness of the database • Foreign keys – Control data redundancies by using common attributes shared by tables • Sometimes, data redundancy is necessary Relational Database Model
- 38. •data anomalies occur when the data to be entered into the system does not work as expected. This usually happens when database consist of redundant data. •3 Types : • UPDATE occurs when changes cannot be completed to the existing records. • INSERTION occurs when new record cannot be entered into the system. • DELETION occurs when deleted historical data cannot be traced after deletion of certain data take place. Data Anomalies Relational Database Model
- 39. • Orderly arrangement to logically access rows in a table • Index key – Index’s reference point – Points to data location identified by the key • Unique index – Index in which the index key can have only one pointer value (row) associated with it • Each index is associated with only one table Indexes Relational Database Model
- 40. SUMMARY • Each table row must have a primary key that uniquely identifies all attributes • Tables are linked by common attributes • The relational model supports relational algebra functions –SELECT, PROJECT, JOIN, INTERSECT UNION, DIFFERENCE, PRODUCT, DIVIDE • Good design begins by identifying entities, attributes, and relationships –1:1, 1:M, M:N
- 41. DISCUSSION Consider the relational database of next relational schema with 3 relations. Underline the best possible primary keys in each relation? EMPLOYEE (person_name, street, city) WORKS (person_name, company_name, salary) COMPANY (company_name, city)
Notas del editor
- (I) Super Key – An attribute or a combination of attribute that is used to identify the records uniquely is known as Super Key. A table can have many Super Keys. E.g. of Super Key 1 ID 2 ID, Name 3 ID, Address 4 ID, Department_ID 5 ID, Salary 6 Name, Address 7 Name, Address, Department_ID ………… So on as any combination which can identify the records uniquely will be a Super Key. (II) Candidate Key – It can be defined as minimal Super Key or irreducible Super Key. In other words an attribute or a combination of attribute that identifies the record uniquely but none of its proper subsets can identify the records uniquely. E.g. of Candidate Key 1 Code 2 Name, Address For above table we have only two Candidate Keys (i.e. Irreducible Super Key) used to identify the records from the table uniquely. Code Key can identify the record uniquely and similarly combination of Name and Address can identify the record uniquely, but neither Name nor Address can be used to identify the records uniquely as it might be possible that we have two employees with similar name or two employees from the same house. (III) Primary Key – A Candidate Key that is used by the database designer for unique identification of each row in a table is known as Primary Key. A Primary Key can consist of one or more attributes of a table. E.g. of Primary Key - Database designer can use one of the Candidate Key as a Primary Key. In this case we have “Code” and “Name, Address” as Candidate Key, we will consider “Code” Key as a Primary Key as the other key is the combination of more than one attribute. (IV) Foreign Key – A foreign key is an attribute or combination of attribute in one base table that points to the candidate key (generally it is the primary key) of another table. The purpose of the foreign key is to ensure referential integrity of the data i.e. only values that are supposed to appear in the database are permitted. E.g. of Foreign Key – Let consider we have another table i.e. Department Table with Attributes “Department_ID”, “Department_Name”, “Manager_ID”, ”Location_ID” with Department_ID as an Primary Key. Now the Department_ID attribute of Employee Table (dependent or child table) can be defined as the Foreign Key as it can reference to the Department_ID attribute of the Departments table (the referenced or parent table), a Foreign Key value must match an existing value in the parent table or be NULL. (V) Composite Key – If we use multiple attributes to create a Primary Key then that Primary Key is called Composite Key (also called a Compound Key or Concatenated Key). E.g. of Composite Key, if we have used “Name, Address” as a Primary Key then it will be our Composite Key. (VI) Alternate Key – Alternate Key can be any of the Candidate Keys except for the Primary Key. E.g. of Alternate Key is “Name, Address” as it is the only other Candidate Key which is not a Primary Key. (VII) Secondary Key – The attributes that are not even the Super Key but can be still used for identification of records (not unique) are known as Secondary Key. E.g. of Secondary Key can be Name, Address, Salary, Department_ID etc. as they can identify the records but they might not be unique.
- Many to many relationships create uncertainty and duplications on data that will eventually result in wrong statements for queries(2). In the below example; Each person can use many banks and each bank can have many customers.
- An entity relationship diagram (ERD), also known as an entity relationship model, is a graphical representation that depicts relationships among people, objects, places, concepts or events within an information technology (IT) system. Relationships, which are represented by diamond shapes, show how two entities share information in the database. In some cases, entities can be self-linked. Cardinality is the mathematical sense just means the number of values in a set. In relationship to databases and ERD, cardinality specifies how many instances of an entity relate to one instance of another entity. Cardinality allows you express the number of each entity that can be associated with another entity.
- is a candidate key that is most appropriate to become main key to uniquely identify each record in a table Primary Key – A Candidate Key that is used by the database designer for unique identification of each row in a table is known as Primary Key. A Primary Key can consist of one or more attributes of a table. E.g. of Primary Key - Database designer can use one of the Candidate Key as a Primary Key. In this case we have “Code” and “Name, Address” as Candidate Key, we will consider “Code” Key as a Primary Key as the other key is the combination of more than one attribute.