Welcome to lesson one of module eight on Developing Business Data Models. I'm going to start with an important question about the nature of conceptual data modeling. What are the characteristics of business data modeling problems? Module eight, extends your data modeling skills. Module six and seven emphasize precise usage of ERD notation, a pre-requisite to developing higher level reasoning skills. Module eight focuses on a development of these higher level skills, assuming you have confidence with ERD notation. You need to have confidence about precisely using ERD notation without diagram errors before developing higher level reasoning skills to develop ERDs that satisfy business data requirements. The objectives in this lesson involve a broad focus on conceptual data modeling to provide a context for skill development. This context will help you to reflect on the skills you learned in other lessons of his module. You should be able to explain the goals of conceptual data modeling in the challenges in analyzing business requirements. The goals of database development were covered in lesson one of module six, but I want to briefly review them again and elaborate on the first two goals and other parts of this lesson. Broadly, the goal of database development is to create a database that provides an important resource for an organization. To fulfill this broad goal, a database should provide a vocabulary for a large community of users, support organizational policies, contain high quality data and provide efficient access. The concepts and skills for conceptual data modeling primarily support the subgoals of developing a common vocabulary in active support of organizational policies. A database provides a common vocabulary for an organization. Before a database is implemented, different parts of an organization may have different terminology. For example, there may be multiple formats for addresses. Multiple ways to identify customers and different ways to calculate interest rates. After a database is implemented, communication can improve among different parts of an organization. Thus, a database can unify an organization by establishing a common vocabulary. Achieving a common vocabulary is not easy. Developing a database requires compromise to satisfy a large community of users. In some sense a good database designer share some characteristics with a good politician. A good politician often finds solutions with which everyone finds something to agree and disagree and establishing a common vocabulary. A good database designer also find similar imperfect solutions. Forging compromises can be difficult, but the results can improve productivity, customer satisfaction and other measures of organizational performance. A database contains business rules to support organizational policies. For example, in a utility billing system, an important rule is that a meter reading must precede billing for resource consumption. A database can contain integrity restraints to support this rule. Defining business rules establishes the meaning of a database, enables a database to actively support organizational policies. This active role contrasts with a more passive role that databases have in establishing of a common vocabulary. In establishing business rules, a database designer must choose appropriate constraint levels. Selecting appropriate constraint levels may require compromise to balance the needs of different user groups. Constraints that are too strict may force work around solutions to handle exceptions. In contrast, constraints that are too loose may allow incorrect data in a database. For example, in a university database, a designer must decide if a course offering can be stored without knowing the instructor. Some user groups may want the instructor to be entered initially to ensure that course commitments can be met. Other user groups may want more flexibility, because course catalogs are typically released well in advance of the beginning of the academic period. Forcing the instructor to be entered at a time, a course offering is stored may be too strict. If the database contains this constraint, users may be forced to circumvent it by using a default value such as TBA for to be announced. The appropriate constraint forcing entry to the instructor or allowing later entry depends on the importance of the needs of the user groups to the goals of the organization. Modules eight and nine cover the process of conceptual data modeling using the ERD notation covered in modules six and seven. The conceptual data modeling phase uses data requirements and produces an ERD to represent the information needs of an organization. Data requirements can have many formats, such as interview with users, documentation of existing systems and proposed forms reports. The conceptual data model should represent all requirements in formats. Typical databases has ERDs involving hundreds of entity types and relationships. I diagram large enough to cover an entire office wall. For large databases, the conceptual data modeling phase is usually modified. Designing large databases is a time consuming and labor intensive process, often involving a team of designers. The development effort can involve requirements from many different groups of users. To manage complexity, a divide and conquer strategy is used in many areas of computing. Dividing a large problem into smaller problems, allows the smaller problems to be solved somewhat independently. The solutions to the smaller problems are then combined into a solution for the entire problem. Although this course does not cover aspects of large database development efforts, course two in the specialization covers project management challenges and design methodologies for data warehouses. Even modest sized data warehouses present major project management and design challenges. Business requirements are rarely well structured, rather as a database designer who often face an ill-defined business situation in which you need to add structure. You'll need to interact with a variety of stakeholders, who sometimes provide competing statements about database requirements. In collecting your requirements, you will conduct interviews, review documents and examine existing data. To determine the scope of the database, you will need to eliminate irrelevant details and add missing details. On large projects, you may work on a subset or requirements and then collaborate with a team of designers to determine the complete data model. A course cannot provide the experience of designing real databases. The more difficult problems can provide insights in to the difficulties of designing real databases, but will not provide you with practice to the actual experience. To acquire this experience, you must augment the concepts and skills you acquire in this course to interact with organizations through projects, internships and job experience. The background acquired through reference in this course provide a foundation to take your database development skills to higher levels. Let's wrap up lesson one about conceptual data modeling goals. This lesson has provided a context for the concept and skills covered in other lessons of modules eight and nine. You should not lose perspective of the goals and challenges of data modeling as you learn about details and develop skills. Although this course does not cover challenges about large database development efforts, course two into specialization will provide background about challenges and design methodologies for data warehouse development. An answer to the opening question about characteristics of business data requirements, you should know a business requirements are typically unstructured with a missions, inconsistencies in irrelevant details. Requirements are provided by diverse group of stakeholders in variety of formats. Putting structure into requirements in resolving visions of a database are challenging and rewarding work opportunities. The remaining lessons of this module focus on an important subset of conceptual data modeling skills. You will learn guidelines for analyzing narrative problems and transformations to help you consider alternative designs.
