Database Design I

Total Page:16

File Type:pdf, Size:1020Kb

Database Design I Database Design • Goal: specification of database schema Database Design I: • Methodology: – Use E-R model to get a high-level graphical view of The Entity-Relationship Model essential components of enterprise and how they are related Chapter 5 – Convert E-R diagram to DDL • E-R Model: enterprise viewed as set of – Entities – Relationships among entities 1 2 Entity Type Entities · Entity type described by set of attributes · Entity: an object that is involved in the ± Student: Id, Name, Address, Hobbies enterprise · Domain: possible values of an attribute ± Ex: John, CSE305 ± Value can be a set (in contrast to relational model) • (111111, John, 123 Main St, (stamps, coins)) · Entity Type: set of similar objects • Key: minimum set of attributes that uniquely ± Ex: students, courses identifies an entity (candidate key) · Attribute: describes one aspect of an entity type • Entity Schema: entity type name, attributes (and ± Ex: name, maximum enrollment associated domain), key constraints 3 4 Representation in Relational Model • Entity type corresponds to a relation Entity Type (con' t) • Relation’s attributes = entity type’s attributes · Graphical Representation in E-R diagram: – Problem: entity type can have set valued attributes. – Solution: Use several rows to represent a single entity • (111111, John, 123 Main St, stamps) • (111111, John, 123 Main St, coins) – Problems with solution: • Redundancy • Key of entity type not key of relation • => resulting relation must be further transformed Set-valued attribute 5 6 •1 Relationship Attributes and Roles · Attribute of a relationship type describes the · Relationship: relates two or more entities · Attribute ± John majors in Computer Science relationship · Relationship Type: set of similar relationships ± e.g., John majors in CS since 2000 ± Student (entity type) related to Department (entity type) · John and CS are related by MajorsIn (relationship type). · 2000 describes relationship - value of SINCE attribute of MajorsIn relationship type · Distinction: MajorsIn ± relation (relational model) - set of tuples · Role of a relationship type names one of the ± relationship (E-R Model) ± describes relationship related entities between entities of an enterprise ± e.g., John is value of Student role, CS value of ± Both entity types and relationship types (E-R model) Department role of MajorsIn relationship type can be represented as relations (relational model) ± (John, CS, 2000) describes a relationship 7 8 Relationship Type Roles · Problem: relationship can relate elements of · Described by set of attributes and roles same entity type ± e.g., MajorsIn: Student, Department, Since ± e.g., ReportsTo relationship type relates two ± Here we have used as the role name (Student) elements of Employee entity type: the name of the entity type (Student) of the · Bob reports to Mary since 2000 participant in the relationship, but ... ± We do not have distinct names for the roles ± It is not clear who reports to whom 9 10 Schema of a Relationship Type Roles (con’ t) • Role names, Ri, and their corresponding entity sets. Roles must be single valued (number of • Solution: role name of relationship type roles = degree) need not be same as name of entity type • Attribute names, Aj, and their corresponding from which participants are drawn domains. Attributes may be set valued – ReportsTo has roles Subordinate and • Key: Minimum set of roles and attributes that Supervisor and attribute Since uniquely identify a relationship – Values of Subordinate and Supervisor both • Relationship: <e1, …en; a1, …ak> drawn from entity type Employee – ei is an entity, a value from Ri’ s entity set – aj is a set of attribute values with elements from domain of Aj 11 12 ·2 Graphical Representation Representation of Relationship Type in Relational Model · Roles are edges labeled with role names (omitted if role name = name of entity set). Most attributes have been omitted. · Attributes of corresponding relation are ± Attributes of relationship type ± For each role, the primary key of the entity type associated with that role · Example: RoomNo DeptId Name SectNo CrsCode Enroll S2000Courses Teaching Professor Id ± S2000Courses (CrsCode, SectNo, Enroll) ± Professor (Id, DeptId, Name) ± Teaching (CrsCode, SecNo, Id, RoomNo) 13 14 Representation in Relational Model Representation in SQL · Candidate key of corresponding table = candidate key of · Each role of relationship type produces a relation ± Except when there are set valued attributes foreign key in corresponding relation ± Example: Teaching (CrsCode, SectNo, Id, RoomNo, TA) ± Foreign key references table corresponding to · Key of relationship type = (CrsCode, SectNo) · Key of relation = (CrsCode, SectNo, TA) entity type from which role values are drawn CrsCode SectNo Id RoomNo TA CSE305 1 22 1234 Hum Joe CSE305 1 22 1234 Hum Mary 15 16 Example 1 Example 2 Date Price Since Status Project Sold Part Professor WorksIn Department Supplier CREATE TABLE WorksIn ( CREATE TABLE Sold ( Since DATE, -- attribute Price INTEGER, -- attribute Status CHAR (10), -- attribute Date DATE, -- attribute ProfId INTEGER, -- role (key of Professor) ProjId INTEGER, -- role DeptId CHAR (4), -- role (key of Department) SupplierId INTEGER, -- role PRIMARY KEY (ProfId), -- since a professor works in at most one department PartNumber INTEGER, -- role FOREIGN KEY (ProfId) REFERENCES Professor (Id), PRIMARY KEY (ProjId, SupplierId, PartNumber, Date), FOREIGN KEY (ProjId) REFERENCES Project, FOREIGN KEY (DeptId) REFERENCES Department ) FOREIGN KEY (SupplierId) REFERENCES Supplier (Id), FOREIGN KEY (PartNumber) REFERENCES Part (Number) ) 17 18 ·3 Key Constraint (special case) Key Constraint (special case) · Relational model representation: key of relation corresponding to entity type is key of relation · If, for a particular participant entity type, corresponding to relationship type each entity participates in at most one ± Id is primary key of Professor; ProfId is key of relationship, corresponding role is a key of WorksIn. Professor 4100 does not participate. ± Cannot use foreign key in Professor since some relationship type professors do not participate ± E.g., Professor role is unique in WorksIn · Representation in E-R diagram: arrow Id ProfId 1123 4100 1123 CSE Professor WorksIn Department 3216 3216 AMS WorksIn 19 Professor 20 Entity Type Hierarchies IsA · One entity type might be subtype of another ± Freshman is a subtype of Student Student · A relationship exists between a Freshman entity Represents four and the corresponding Student entity IsA relationship types ± e.g., Freshman John is related to Student John · This relationship is called IsA ± Freshman IsA Student Freshman Sophmore Junior Senior ± The two entities related by IsA are always descriptions of the same real-world object 21 22 Properties of IsA IsA · Inheritance - Attributes of supertype apply to subtype. · Advantage: Used to create a more concise ± E.g., GPA attribute of Student applies to Freshman and readable E-R diagram ± Subtype inherits all attributes of supertype. ± Attributes common to different entity sets need ± Key of supertype is key of subtype not be repeated · Transitivity - Hierarchy of IsA ± They can be grouped in one place as attributes ± Student is subtype of Person, Freshman is of supertype subtype of Student, so Freshman is also a ± Attributes of (sibling) subtypes can be different subtype of Student 23 24 ·4 IsA Hierarchy - Example Type Hierarchy · Might have associated constraints: ± Covering constraint: Union of subtype entities is equal to set of supertype entities · Employee is either a secretary or a technician (or both) ± Disjointness constraint: Sets of subtype entities are disjoint from one another · Freshman, Sophomore, Junior, Senior are disjoint sets · Might be related to fragmentation of data 25 26 Type Hierarchies and Relational Model Type Hierarchies and Relational Model · Supertypes and subtypes can be realized as Id attribs0 separate relations Student ± Need a way of identifying subtype entity with its (unique) related supertype entity · Choose a candidate key and make it an attribute of all entity types in hierarchy Id attribs1 Id attribs2 Id attribs3 Id attribs4 Freshman Sophmore Junior Senior 27 28 Participation Constraint Type Hierarchies and Relational Model · If every entity participates in at least one relationship, a participation constraint · Redundancy eliminated if IsA is not disjoint holds: ± For individuals who are both employees and ± A participation constraint of entity type E students, Name and DOB are stored once having role ρ in relationship type R states that for e in E there is an r in R such that ρ(r) = e. Person Employee Student ± e.g., every professor works in at least one department SSN Name DOB SSN Department Salary SSN GPA StartDate 1234 Mary 1950 1234 Accounting 35000 1234 3.5 1997 Reprsentation in E-R Professor WorksIn Department 29 30 ·5 Representing Participation Constraints Participation Constraint in Relational · Inclusion dependency: Every professor works in at least one dep' t. Model ± in relational model: (easy) · Professor (Id) references WorksIn (ProfId) ± in SQL: · Example (can' t use foreign key in Professor) · Special case: Every professor works in exactly one dep' t. (easy) ± FOREIGN KEY Id REFERENCES WorksIn (ProfId) ProfId Id · General case (not so easy): 1123 CSE 1123 1123 AMS 4100 CREATE ASSERTION ProfsInDepts 4100 ECO 3216 CHECK ( NOT EXISTS ( 3216 AMS SELECT * FROM Professor P Professor WHERE NOT EXISTS ( WorksIn SELECT * FROM WorksIn W WHERE
Recommended publications
  • Form Follows Function Model-Driven Engineering for Clinical Trials
    Form Follows Function Model-Driven Engineering for Clinical Trials Jim Davies1, Jeremy Gibbons1, Radu Calinescu2, Charles Crichton1, Steve Harris1, and Andrew Tsui1 1 Department of Computer Science, University of Oxford Wolfson Building, Parks Road, Oxford OX1 3QD, UK http://www.cs.ox.ac.uk/firstname.lastname/ 2 Computer Science Research Group, Aston University Aston Triangle, Birmingham B4 7ET, UK http://www-users.aston.ac.uk/~calinerc/ Abstract. We argue that, for certain constrained domains, elaborate model transformation technologies|implemented from scratch in general- purpose programming languages|are unnecessary for model-driven en- gineering; instead, lightweight configuration of commercial off-the-shelf productivity tools suffices. In particular, in the CancerGrid project, we have been developing model-driven techniques for the generation of soft- ware tools to support clinical trials. A domain metamodel captures the community's best practice in trial design. A scientist authors a trial pro- tocol, modelling their trial by instantiating the metamodel; customized software artifacts to support trial execution are generated automati- cally from the scientist's model. The metamodel is expressed as an XML Schema, in such a way that it can be instantiated by completing a form to generate a conformant XML document. The same process works at a second level for trial execution: among the artifacts generated from the protocol are models of the data to be collected, and the clinician conduct- ing the trial instantiates such models in reporting observations|again by completing a form to create a conformant XML document, represent- ing the data gathered during that observation. Simple standard form management tools are all that is needed.
    [Show full text]
  • Jsfa [email protected]
    John Sergio Fisher & Associates Inc. 5567 Reseda Blvd. Suite 209 Los Angeles, CA 91356 818.344.3045 Fax 818.344.0338 jsfa [email protected] July 18, 2019 Peter Tauscher, Senior Civil Engineer City of Newport Beach – Public Works Department Newport Beach Library Lecture Hall Building Project 100 Civic Center Drive Newport Beach, CA 92660 Dear Mr. Tauscher, John Sergio Fisher & Associates, Inc. (JSFA) is most honored to submit a proposal for the Newport Beach Library Lecture Hall Building Project. We are architects, planners/ urban designers, interior designers, theatre consultants and acoustical consultants with offices in Los Angeles and San Francisco. We’ve been in business 42 years involved primarily with cultural facilities for educational and civic institutions with a great majority of that work being for performance facilities. We are experts in seating arrangements whether they be for lecture halls, theatres/ concert halls or recital halls. We have won many design awards including 48 AIA design excellence awards and our work has been published regionally, nationally and abroad. We use a participatory programming and design process involving the city and the stakeholders. We pride ourselves in delivering award- winning, green building designs on time and on budget. Our current staff is 18 and our principals are involved with every project. Thank you for inviting us and for your consideration. Sincerely, John Sergio Fisher & Associates, Inc. John Fisher, AIA President 818.344.3045 Fax: 818.344.0338 Architecture Planning/Urban Design Interiors Arts/Entertainment Facilities Theatre Consulting Acoustical Consulting Los Angeles San Francisco jsfa Table of Contents Tab 1 1.
    [Show full text]
  • XXI. Database Design
    Information Systems Analysis and Design CSC340 XXI. Database Design Databases and DBMS Data Models, Hierarchical, Network, Relational Database Design Restructuring an ER schema Performance analysis Analysis of Redundancies, Removing generalizations Translation into a Relational Schema The Training Company Example Normal Forms and Normalization of Relational Schemata © 2002 John Mylopoulos Database Design -- 1 Information Systems Analysis and Design CSC340 Databases n A database is a collection of persistent data shared by a number of applications n Databases have been founded on the concept of data independence: Applications should not have to know the organization of the data or the access strategy employed Need query processing facility, which generates automatically an access plan, given a query n Databases also founded on the concept of data sharing: Applications should be able to work on the same data concurrently, without knowing of each others’ existence. Þ Database procedures defined in terms of atomic operations called transactions © 2002 John Mylopoulos Database Design -- 2 1 Information Systems Analysis and Design CSC340 Conventional Files vs Databases Databases Advantages -- Good for data integration; allow for more flexible Files formats (not just records) Advantages -- many already exist; good for simple applications; very Disadvantages -- high cost; efficient drawbacks in a centralized facility Disadvantages -- data duplication; hard to evolve; hard to build for complex applications The future is with databases! © 2002 John
    [Show full text]
  • Database Performance Study
    Database Performance Study By Francois Charvet Ashish Pande Please do not copy, reproduce or distribute without the explicit consent of the authors. Table of Contents Part A: Findings and Conclusions…………p3 Scope and Methodology……………………………….p4 Database Performance - Background………………….p4 Factors…………………………………………………p5 Performance Monitoring………………………………p6 Solving Performance Issues…………………...............p7 Organizational aspects……………………...................p11 Training………………………………………………..p14 Type of database environments and normalizations…..p14 Part B: Interview Summaries………………p20 Appendices…………………………………...p44 Database Performance Study 2 Part A Findings and Conclusions Database Performance Study 3 Scope and Methodology The authors were contacted by a faculty member to conduct a research project for the IS Board at UMSL. While the original proposal would be to assist in SQL optimization and tuning at Company A1, the scope of such project would be very time-consuming and require specific expertise within the research team. The scope of the current project was therefore revised, and the new project would consist in determining the current standards and practices in the field of SQL and database optimization in a number of companies represented on the board. Conclusions would be based on a series of interviews with Database Administrators (DBA’s) from the different companies, and on current literature about the topic. The first meeting took place 6th February 2003, and interviews were held mainly throughout the spring Semester 2003. Results would be presented in a final paper, and a presentation would also be held at the end of the project. Individual summaries of the interviews conducted with the DBA’s are included in Part B. A representative set of questions used during the interviews is also included.
    [Show full text]
  • Data Quality Requirements Analysis and Modeling December 1992 TDQM-92-03 Richard Y
    Published in the Ninth International Conference of Data Engineering Vienna, Austria, April 1993 Data Quality Requirements Analysis and Modeling December 1992 TDQM-92-03 Richard Y. Wang Henry B. Kon Stuart E. Madnick Total Data Quality Management (TDQM) Research Program Room E53-320 Sloan School of Management Massachusetts Institute of Technology Cambridge, MA 02139 USA 617-253-2656 Fax: 617-253-3321 Acknowledgments: Work reported herein has been supported, in part, by MITís Total Data Quality Management (TDQM) Research Program, MITís International Financial Services Research Center (IFSRC), Fujitsu Personal Systems, Inc. and Bull-HN. The authors wish to thank Gretchen Fisher for helping prepare this manuscript. To Appear in the Ninth International Conference on Data Engineering Vienna, Austria April 1993 Data Quality Requirements Analysis and Modeling Richard Y. Wang Henry B. Kon Stuart E. Madnick Sloan School of Management Massachusetts Institute of Technology Cambridge, Mass 02139 [email protected] ABSTRACT Data engineering is the modeling and structuring of data in its design, development and use. An ultimate goal of data engineering is to put quality data in the hands of users. Specifying and ensuring the quality of data, however, is an area in data engineering that has received little attention. In this paper we: (1) establish a set of premises, terms, and definitions for data quality management, and (2) develop a step-by-step methodology for defining and documenting data quality parameters important to users. These quality parameters are used to determine quality indicators, to be tagged to data items, about the data manufacturing process such as data source, creation time, and collection method.
    [Show full text]
  • Chapter 9 – Designing the Database
    Systems Analysis and Design in a Changing World, seventh edition 9-1 Chapter 9 – Designing the Database Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases Instructor's Notes (for each section) ◦ Key Terms ◦ Lecture notes ◦ Quick quizzes Classroom Activities Troubleshooting Tips Discussion Questions Chapter Overview Database management systems provide designers, programmers, and end users with sophisticated capabilities to store, retrieve, and manage data. Sharing and managing the vast amounts of data needed by a modern organization would not be possible without a database management system. In Chapter 4, students learned to construct conceptual data models and to develop entity-relationship diagrams (ERDs) for traditional analysis and domain model class diagrams for object-oriented (OO) analysis. To implement an information system, developers must transform a conceptual data model into a more detailed database model and implement that model in a database management system. In the first sections of this chapter students learn about relational database management systems, and how to convert a data model into a relational database schema. The database sections conclude with a discussion of database architectural issues such as single server databases versus distributed databases which are deployed across multiple servers and multiple sites. Many system interfaces are electronic transmissions or paper outputs to external agents. Therefore, system developers need to design and implement integrity controls and security controls to protect the system and its data. This chapter discusses techniques to provide the integrity controls to reduce errors, fraud, and misuse of system components. The last section of the chapter discusses security controls and explains the basic concepts of data protection, digital certificates, and secure transactions.
    [Show full text]
  • Database-Design-1375466250.Pdf
    Database Design Database Design Adrienne Watt Port Moody Except for third party materials and otherwise stated, content on this site is made available under a Creative Commons Attribution 2.5 Canada License. This book was produced using PressBooks.com, and PDF rendering was done by PrinceXML. Contents Preface v 1. Chapter 1 Before the Advent of Database Systems 1 2. Chapter 2 Fundamental Concepts 4 3. Chapter 3 Characteristics and Benefits of a Database 7 4. Chapter 4 Types of Database Models 10 5. Chapter 5 Data Modelling 13 6. Chapter 6 Classification of Database Systems 18 7. Chapter 7 The Relational Data Model 21 8. Chapter 8 Entity Relationship Model 26 9. Chapter 9 Integrity Rules and Constraints 37 10. Chapter 10 ER Modelling 44 11. Chapter 11 Functional Dependencies 49 12. Chapter 12 Normalization 53 13. Chapter 13 Database Development Process 59 14. Chapter 14 Database Users 67 Appendix A University Registration Data Model example 69 Appendix B ERD Exercises 74 References and Permissions 77 About the Author 79 iv Preface v vi Database Design The primary purpose of this text is to provide an open source textbook that covers most Introductory Data- base courses. The material in the textbook was obtained from a variety of sources. All the sources are found in the reference section at the end of the book. I expect, with time, the book will grow with more information and more examples. I welcome any feedback that would improve the book. If you would like to add a section to the book, please let me know.
    [Show full text]
  • Designing High-Performance Data Structures for the Couchbase Data Platform
    Designing High-Performance Data Structures for the Couchbase Data Platform The NoSQL Data Modeling Imperative Danny Sandwell, Product Marketing, erwin, Inc. Leigh Weston, Product Management, erwin, Inc. Learn More at erwin.com When Not DBMS products based on rigid schema requirements impede our ability to fully realize business opportunities that can expand the depth and breadth of relevant data streams “If” NoSQL for conversion into actionable information. New, business-transforming use cases often involve variable data feeds, real-time or near-time processing and analytics requirements, We’ve heard the and the scale to process large volumes of data. NoSQL databases, such as the Couchbase business case Data Platform, are purpose-built to handle the variety, velocity and volume of these new data use cases. Schema-less or dynamic schema capabilities, combined with increased and accepted processing speed and built-in scalability, make NoSQL, and Couchbase in particular, the the modern ideal platform. technology Now the hard part. Once we’ve agreed to make the move to NoSQL, the next step is justifications to identify the architectural and technological implications facing the folks tasked with for adopting building and maintaining these new mission-critical data sources and the applications they feed. As the data modeling industry leader, erwin has identified a critical success factor for NoSQL database the majority of organizations adopting a NoSQL platform like Couchbase. management Successfully leveraging this solution requires a significant paradigm shift in how we design system (DBMS) NoSQL data structures and deploy the databases that manage them. But as with most solutions to technology requirements, we need to shield the business from the complexity and risk support data- associated with this new approach.
    [Show full text]
  • Database Design Document
    SunGuideSM: Database Design Document SunGuide-DBDD-1.0.0-Preliminary Prepared for: Florida Department of Transportation ITS Office 605 Suwannee Street, M.S. 90 Tallahassee, Florida 32399-0450 (850) 410-5600 February 19, 2004 Database Detailed Design Document Control Panel File Name: SunGuide-DBDD-1.0.0-Preliminary File Location: SunGuide CM Repository CDRL: 2-3.1 Name Initial Date Created By: Tammy Duncan, SwRI TD 12/05/03 James Halbert, SwRI JH 12/05/03 Reviewed By: Robert Heller, SwRI RWH 2/18/04 Steve Dellenback, SwRI SWD 2/19/04 Steve Novosad, SwRI SEN 2/05/04 Susan Crumrine, SwRI SBC 2/19/04 Modified By: Completed By: SunGuide-DBDD-1.0.0-Preliminary i Database Detailed Design Table of Contents 1. Scope..................................................................................................1 1.1 Document Identification............................................................................ 1 1.2 Project Overview ....................................................................................... 1 1.3 Related Documents ................................................................................... 2 1.4 Contacts ..................................................................................................... 2 2. Conceptual Model..............................................................................4 2.1 System Context ......................................................................................... 4 2.2 Purpose of Database................................................................................
    [Show full text]
  • A Knowledge-Based System for Physical Database Design
    AlllDE 7mfi2D NATL INST OF STANDARDS & TECH R.I.C. r Computer Science A1 11 02764820 abrowskl, Chrlstoph/A knowledge-based s QC100 .U57 NO.500-151 1988 V19 C.I NBS-P and Technology PUBLICATIONS NBS Special Publication 500-151 A Knowledge-Based System for Physical Database Design Christopher E. Dabrowski and David K. Jefferson #500-151 1988 C.2 Tm he National Bureau of Standards' was established by an act of Congress on March 3, 1901. The Bureau's overall is to strengthen and advance the nation's science and technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research to assure international competitiveness and leadership of U.S. industry, science arid technology. NBS work involves development and transfer of measurements, standards and related science and technology, in support of continually improving U.S. productivity, product quality and reliability, innovation and underlying science and engineering. The Bureau's teclmical work is performed by the National Measurement Laboratory, the National Engineering Laboratory, the Institute for Computer Sciences and Technology, and the Institute for Materials Science and Engineering. The National Measurement Laboratory Provides the national system of physical and chemical measurement; • Basic Standards^ coordinates the system with measurement systems of other nations and • Radiation Research furnishes essential services leading to accurate and uniform physical and • Chemical Physics chemical measurement throughout the Nation's scientific community, • Analytical Chemistry industry, and commerce; provides advisory and research services to other Government agencies; conducts physical and chemical research; develops, produces, and distributes Standard Reference Materials; provides calibration services; and manages the National Standard Reference Data System.
    [Show full text]
  • Development of Concept Plan for the Route 1 North Area
    September 29, 2016 | RFP Town of Falmouth Development of Concept Plan for the Route 1 North Area www.vhb.com September 29, 2016 Nathan Poore Town Manager Town of Falmouth 271 Falmouth Road Falmouth, Maine 04105 Re: Development of Concept Plan for the Route 1 North Area Dear Mr. Poore: The Town of Falmouth has embarked on an important initiative aimed at exploring opportunities to enhance its local economy and increase revenues through a variety of planning and policy efforts focused on the Route 1 North corridor. The Town of Falmouth 2013 Comprehensive Plan designated the Route 1 corridor as a Desginated Growth Area, and the Town is seeking a qualified team to help develop a Concept Plan for the Route 1 North Area that not only describes a future vision for the corridor, but also describes how best to direct Town resources to support that vision. To undertake this effort, the Town needs a multidisciplinary team with a depth of experience in zoning, land use planning, market analysis, economic development, transportation, site/civil engineering and civic en- gagement. VHB is ready to help you through this process by facilitating creative, sustainable, and implementable solutions, and turning the Town’s vision into reality. VHB is a multidisciplinary firm with 23 offices along the east coast, including an office in South Portland. We pro- vide planning, engineering, transportation, landscape architecture, and environmental services. Over the past 35 years, we have had the privilege of working with communities throughout New England on comprehensive plans, zoning, and economic development studies. To guide this process, we will leverage lessons learned on land use planning, visioning, strategic planning, market analysis, and environmental and infrastructure assessments for municipalities throughout the region.
    [Show full text]
  • Applying Tssl in Database Schema Modeling: Visualizing the Syntax of Gradual Transitions
    Journal of Technology and Science Education JOTSE, 2018 – 8(4): 238-253 – Online ISSN: 2013-6374 – Print ISSN: 2014-5349 https://doi.org/10.3926/jotse.365 APPLYING TSSL IN DATABASE SCHEMA MODELING: VISUALIZING THE SYNTAX OF GRADUAL TRANSITIONS Adi Katz Sami Shamoon College of Engineering (SCE) (Israel) [email protected] Received December 2017 Accepted February 2018 Abstract Since database conceptual modeling is a complex cognitive activity, finding an appropriate pedagogy to deliver the topic to novice database designers is a challenge for Information Systems (IS) educators. The four-level TSSL model that is known in the area of human-computer interactions (HCI) is used to explain and demonstrate how instructional design can minimize extraneous cognitive load in the conceptual modeling task of designing a database schema. The instructional design approach puts focus on the syntactic level of TSSL, to explain how visualizing gradual transitions between hierarchic levels of the schema is effective in database modeling. The current work demonstrates the approach, and at the next phase we plan to experimentally test the effectiveness of the approach by comparing performance and attitudes of students who are exposed to emphasizing the syntax of the gradual transitions in schema structure to those who are not exposed to it. Keywords – Conceptual modeling, Database schema, TSSL, Pedagogy, Visualization. ---------- 1. Introduction This is a pedagogic research that offers an approach for effectively delivering and instructing the activity of relational database schema modeling to novice database designers. Modeling users’ requirements is a very important task in information system analysis and design, to ensure that the intended system would meet organizational goals (Dahan, Shoval & Sturm, 2014).
    [Show full text]