E N D
Module 2:1 Introduction
Describing a Family Tree • Both my great grandparents had 2 children each. My Father had 4 siblings with 3 children each. My Mother had 3 siblings with 2 children each. My Father had 2 other Cousins with 2 children each. My Mother had 2 cousins with 3 children each. We are 5 in my family
Question • How many 1st degree cousins do I have? 2nd degree? How many cousins do we have in the whole clan? Great grand children? • Given that all my titos and titas will give my 500 for christmas, how many will I receive by the 26th? • How many are we all in all?
Math • Solve for all cousins: • Father Side • Father siblings = 4 x 3 children each = 12 • Father cousin = 2 x 2 children each = 4 • Father side = Father sibling + Father cousin • Father side = 16 children • Mother Side • Mother sibling = 3 x 2 children each = 6 • Mother cousin = 2 x 3 children each = 6 • Mother side = Mother sibling + Mother cousin • Mother side = 12 • Cousins = Motherside + Fatherside = 16+12 = 28
Math • Solve for all greatgrandchildren: • Since Father Side = 16 and Mother Side =12 • And FatherMotherchildren = 5 children • FS+MS+FMC= 16+12+5 = 33 • Solve for Titostitas: • Fatherside: • Let FGGParents = (FGParentsA + FGParentsB) x 2 • FGParentsA= 2 ; FGParentsB = 4 • FGGParents = (2+4)2 = 12 • Motherside • MGGParents = (MGParentsA + MGParentsB) x 2 • MGParentsA= 2 ; FGParentsB = 3 • MGGParents = (2+3)2= 10 • Christmas_Aguinaldo=(Motherside+Fatherside)xP500 • Christmas_aguinaldo=(10+12)x500=(22)xP500)=11,000
Math • How many are we all in all • Since all siblings = 33 • Titos and Titas = 22 • Grandparents = 2 x 2 = 4 x 2 = 8 • Great grand parents = 2 x 2 = 4 • Parents = 2 • Allinall=33+22+8+4+2= 69
Introduction • Data models… • Relatively simple representations • Usually graphical • Of a more complex real-world data structure • …supported by powerful database design tools have made it possible to substantially diminish the errors of database design.
Function of a Data Model • help understand the complexities of a real-world object or event • It represents data structures and their: • Characteristics • Relations • Constrains • Transformations
Module 2:1 1 Building blocks of data models
Histories of Database Designs • 1950s and early 1960s: • Data processing using magnetic tapes for storage • Tapes provide only sequential access • Punched cards for input • Late 1960s and 1970s: • Hard disks allow direct access to data • Network and hierarchical data models in widespread use • Ted Codd defines the relational data model • Would win the ACM Turing Award for this work • IBM Research begins System R prototype • UC Berkeley begins Ingres prototype • High-performance (for the era) transaction processing
Histories of Database Designs • 1980s: • Research relational prototypes evolve into commercial systems • SQL becomes industry standard • Parallel and distributed database systems • Object-oriented database systems • 1990s: • Large decision support and data-mining applications • Large multi-terabyte data warehouses • Emergence of Web commerce • 2000s: • XML and XQuery standards • Automated database administration • Increasing use of highly parallel database systems • Web-scale distributed data storage systems
Data Modeling • A collection of tools for describing • Data entities • Data attributes • Data relationships • Data constraints
Data entities • Anything! Person, Place or thing, or events which data are to be collected and stored • An entity represents a particular type of object in a real world • Physical objects • customers • Products
Data Attributes • Characteristics of an entity • Example: the Attributes of a Customer are: • Firstname • Lastname • Course • Year
Data Relationships • Association among entities • Example: • The relationship between customers and an agent • Types of Relationship • One to Many (1:M) relationship • Many to Many (M:N) relationship • One to One (1:1) relationship
Data Relationships • 1:Many (1:M) • Store Employees • Many:Many (M:N) • Employees Skills • 1:1 (1:1) • Employee Store
Entity Relationship Model • Models an enterprise as a collection of entities and relationships • Entity: a “thing” or “object” in the enterprise that is distinguishable from other objects • Described by a set of attributes • Relationship: an association among several entities • Represented diagrammatically by an entity-relationship diagram:
Diagraming using Ched’s Entity Relational Diagram Painter Employee Employee M 1 1 paints learns manages N M 1 Painting skills store
Example of Data Relationships • Example of tabular data in the relational model
Data Constrains • Restrictions placed on the data • This ensures data integrity • Usually in a form of rulews • Examples • QPI: Not less than 0.00 not more than 4.00 • A class should only have a maximum of 45 students • A teacher should only have 21 units or 7 subjects • An uyab should have one and only one uyab.
Data Abstraction • Physical level: describes how a record (e.g., customer) is stored. • Logical level: describes data stored in database, and the relationships among the data. type customer = record customer_id : string; customer_name : string;customer_street : string;customer_city : string; end; • View level: application programs hide details of data types. Views can also hide information (such as an employee’s salary) for security purposes.
View of Data • An architecture for a database system
Module 2:1 2 Business Rules
Understanding the Organization • Before database designers start designing databases (entities, attributes and relationships), they understand first the business rules.
Business Rules • A business rule is • Brief • Precise • And unambiguous • Description of • Policies • Procedures • And principles • Of a specific organization
Enforces order • Business rules help to create and enforce action within that organization’s environment • It is rendered in writing and updated to reflect any changes in the organization’s operational environment
Examples of Business rules and procedures • A customer may generate many invoices • An invoice is generated by one customer • A training session cannot be scheduled for fewer that 10 employees or for more than 30 employees.
Examples of Business rules and procedures • A customer may generate many invoices(1:M relationship) • An invoice is generated by one customer(1:M relationship) • A training session cannot be scheduled for fewer that 10 employees or for more than 30 employees.(1:M relationship with a constrain)
Module 2:1 3 Translating business rules into data model components
Things to consider • What are the Business Rules? Site all of it. • In every business rule, look for its entities and attributes • Are there relationships from it? • From the business rules, identify possible constrains.
Case Discussion • Enrolling a Subject IM32 • Business Rules • A class should have a maximum of 45 students • A student can’t enroll twice on a class on the same semester. • There should be one teacher per class. • Only 3rd and 4th year IM students are allowed to enroll in the class
Case Discussion • Enrolling a Subject IM32 • Entities • Class • Student • Teacher
Case Discussion • Enrolling a Subject IM32 • Attributes • Class • Seats, Subject Code,SubjectDescription,Schedule • Student • Name, year, course • Teacher • Name, Subject, Schedule
Case Discussion • Enrolling a Subject IM32 • Constrains • Class not exceed 45 students • Teacher not exceed 45 students
Case Discussion • Enrolling a Subject IM32 • Relationships • Class • 1 Class 1 Teacher • 1 Class 45 students • Student • 1 Student 1 Class • Teacher • 1 Teacher Many students • 1 Teacher 1 Class • 1 Teacher 1 Class schedule
Diagraming Class Teacher Teacher M 1 1 enrols teaches handles N M 1 student skills Class
Module 2:1 Summary
Point # 1 • Data Model is a (relatively) simple abstraction of complex real-world data environment. Database designers ause data models to communicate with application programmers and end users.
Point #2 • Basic data-modeling components are entities, attributes , relationships and constrains
Point #3 • Business rules are used to identify and define the basic modeling components within a specific real-world environment
Module 2:1 End