{"id":36,"date":"2013-12-12T00:09:52","date_gmt":"2013-12-12T00:09:52","guid":{"rendered":"http:\/\/opentextbc.ca\/dbdesign01\/?post_type=chapter&#038;p=36"},"modified":"2019-06-11T15:56:17","modified_gmt":"2019-06-11T15:56:17","slug":"chapter-5-data-modelling","status":"publish","type":"chapter","link":"https:\/\/opentextbc.ca\/dbdesign01\/chapter\/chapter-5-data-modelling\/","title":{"raw":"Chapter 5 Data Modelling","rendered":"Chapter 5 Data Modelling"},"content":{"raw":"<em>Data modelling<\/em> is the first step in the process of database design. This step is sometimes considered to be\u00a0a high-level and abstract design phase, <span>also referred to as conceptual design<\/span>. The aim of this phase is\u00a0to describe:\r\n<ul>\r\n \t<li>The\u00a0data contained in the database (e.g., entities: students, lecturers, courses, subjects)<\/li>\r\n \t<li>The relationships between data items (e.g., students are supervised by lecturers; lecturers teach courses)<\/li>\r\n \t<li>The constraints on data (e.g., student number has exactly eight\u00a0digits; a subject has four\u00a0or six\u00a0units of credit only)<\/li>\r\n<\/ul>\r\n<span>In the second step<\/span>, the data items, the relationships and the constraints are all expressed using the concepts provided by the high-level data model. Because these concmepts do not include the implementation details, the result of the data modelling process is a (semi) formal representation of the database structure. This result is quite easy to understand so it is used as reference to make sure that all the user\u2019s requirements are met.\r\n\r\n<span>The third step is database design<\/span>. During this step, we might have two sub-steps:\u00a0one called <em>database logical design<\/em>, which defines a database in a data model of a specific DBMS, and another called <em>database physical design<\/em>, which defines the internal database storage structure, file organization or indexing techniques. These two sub-steps\u00a0are database implementation and operations\/user interfaces building steps.\r\n\r\nIn the database design phases, data are represented using a certain data model. The <em>data model<\/em> is a collection of concepts or notations for describing data, data relationships, data semantics and data constraints. Most data models also include a set of basic operations for manipulating data in the database.\r\n<h2>Degrees of Data Abstraction<\/h2>\r\nIn this section we will look at the database design process in terms of specificity.\u00a0Just as any design starts at a high level and proceeds to an ever-increasing level of detail, so does database design.\u00a0For example, when building a home, you start with how many bedrooms and bathrooms the home will have, whether it\u00a0will be on one level or multiple levels, etc.\u00a0The next step is to get an architect to design the home from a more structured perspective. This level gets more detailed with respect to actual room sizes, how the home will be wired, where the plumbing fixtures will be placed, etc.\u00a0The last step is to hire a contractor to build the home.\u00a0That\u2019s looking at the design from a high level of abstraction to an increasing\u00a0level of\u00a0detail.\r\n\r\nThe database design is very much like that. It starts with users identifying the business rules; then the database designers and analysts create the database design; and then the database administrator implements the design using a DBMS.\r\n\r\nThe following subsections summarize the models in order of decreasing level of\u00a0abstraction.\r\n<h3>External models<\/h3>\r\n<ul>\r\n \t<li>Represent the user\u2019s view of the database<\/li>\r\n \t<li>Contain multiple different external views<\/li>\r\n \t<li>Are\u00a0closely related to the real world as perceived by each user<\/li>\r\n<\/ul>\r\n<h3>Conceptual models<\/h3>\r\n<ul>\r\n \t<li>Provide flexible data-structuring capabilities<\/li>\r\n \t<li>Present a \"community view\": the logical structure of the entire database<\/li>\r\n \t<li><span>Contain data stored in the database<\/span><\/li>\r\n \t<li>Show relationships among data including:\r\n<ul>\r\n \t<li>Constraints<\/li>\r\n \t<li>Semantic information (e.g., business rules)<\/li>\r\n \t<li>Security and\u00a0integrity information<\/li>\r\n<\/ul>\r\n<\/li>\r\n \t<li>Consider a database as a collection of entities (objects) of various kinds<\/li>\r\n \t<li>Are the basis for identification and high-level description of main data objects; they avoid details<\/li>\r\n \t<li>Are database independent regardless of the database you will be using<\/li>\r\n<\/ul>\r\n<h3>Internal models<\/h3>\r\nThe three\u00a0best-known models of this kind are the relational data model, the network data model and the hierarchical data model. These internal models:\r\n<ul>\r\n \t<li>Consider a database as a collection of fixed-size records<\/li>\r\n \t<li>Are\u00a0closer to the physical level or file structure<\/li>\r\n \t<li>Are\u00a0a representation of the database as seen by the DBMS.<\/li>\r\n \t<li>Require the designer to match the conceptual model\u2019s characteristics and constraints to those of the selected implementation model<\/li>\r\n \t<li>Involve mapping the entities in the conceptual model to the tables in the relational model<\/li>\r\n<\/ul>\r\n<h3>Physical models<\/h3>\r\n<ul>\r\n \t<li>Are the physical representation of the database<\/li>\r\n \t<li>Have the lowest level of abstractions<\/li>\r\n \t<li>Are\u00a0how the data is stored; they deal with\r\n<ul>\r\n \t<li>Run-time performance<\/li>\r\n \t<li>Storage utilization and\u00a0compression<\/li>\r\n \t<li>File organization and\u00a0access methods<\/li>\r\n \t<li>Data encryption<\/li>\r\n<\/ul>\r\n<\/li>\r\n \t<li>Are the physical level \u2013 managed by<span> the <em>operating system<\/em><\/span><em>\u00a0(OS)<\/em><\/li>\r\n \t<li>Provide concepts that describe the details of how data are stored in the computer\u2019s memory<\/li>\r\n<\/ul>\r\n<h2>Data Abstraction Layer<\/h2>\r\nIn a pictorial view, you can see how the different models work together. Let\u2019s look at this from the highest level, the external model.\r\n\r\nThe external model is the end user's view of the data. Typically a database is an enterprise system that serves the needs of multiple departments. However, one department is not interested in seeing other departments\u2019 data\u00a0(e.g., the\u00a0human resources (HR) department does not care to view the sales department's data). Therefore, one user view will differ from another.\r\n\r\nThe external model requires that the designer subdivide a set of requirements and constraints into functional modules that can be examined within the framework of their external models (e.g., human resources versus sales).\r\n\r\nAs a data designer, you need to understand all the data so that you can build an enterprise-wide database. Based on the needs of various departments, the conceptual model is the first model created.\r\n\r\nAt this stage, the conceptual model is independent of both software and hardware. It does not depend on the DBMS software used to implement the model. It does not depend on the hardware used in the implementation of the model. Changes in either hardware or DBMS software have no effect on the database design at the conceptual level.\r\n\r\nOnce a DBMS is selected, you can then implement it. This is the internal model. Here you create all the tables, constraints, keys, rules, etc.\u00a0 This is often referred to as the <em>logical design<\/em>.\r\n\r\nThe physical model is simply the way the data is stored on disk. Each database vendor has its\u00a0own way of storing the data.\r\n\r\n[caption id=\"attachment_42\" align=\"aligncenter\" width=\"300\"]<a href=\"http:\/\/opentextbc.ca\/dbdesign01\/wp-content\/uploads\/sites\/11\/2013\/12\/Table-Description-300x146.jpg\"><img class=\"wp-image-42\" alt=\"Three stick figures and the words &quot;End Users&quot; at the top. Under that is a yellow rectangle labelled External Model. Inside the \" src=\"http:\/\/opentextbc.ca\/dbdesign01\/wp-content\/uploads\/sites\/11\/2013\/12\/Data-Abstraction-300x226.jpg\" height=\"226\" width=\"300\" \/><\/a> Figure 5.1. Data abstraction layers.[\/caption]\r\n<h2>Schemas<\/h2>\r\nA <em>schema<\/em> is an overall description of a database, and it is usually represented by the\u00a0<em>entity relationship diagram (ERD)<\/em>. There are many subschemas that represent external models and thus display external views of the data. Below is a list of items to consider during the design process of a database.\r\n<ul>\r\n \t<li>External schemas: there are multiple<\/li>\r\n \t<li>Multiple subschemas: these display multiple external views of the data<\/li>\r\n \t<li>Conceptual schema: there is only one. This schema includes data items, relationships and\u00a0constraints, all represented in an ERD.<\/li>\r\n \t<li>Physical schema: there is only one<\/li>\r\n<\/ul>\r\n<h2>Logical and Physical Data Independence<\/h2>\r\n<em>Data independence<\/em> refers to the immunity of user applications to changes made in the definition and organization of data. Data abstractions expose only those items that are important or pertinent to the user. Complexity is hidden from the database user.\r\n\r\nData independence and operation independence together form\u00a0the feature of data abstraction. There are two types of data independence: logical and physical.\r\n<h3>Logical data independence<\/h3>\r\nA<em> logical schema <\/em>is\u00a0a\u00a0conceptual design of the database done on paper or a whiteboard, much like architectural drawings for a house. The ability to change the logical schema,\u00a0without changing the <span><em>external schema<\/em>\u00a0or user view,\u00a0<\/span>\u00a0is called <em>logical data independence<\/em>. For example, the addition or removal of new entities, attributes or relationships to this <em>conceptual schema<\/em> should be possible without having to change existing external schemas or rewrite existing application programs.\u00a0<em>\u00a0<\/em>\r\n\r\nIn other words, changes to\u00a0the logical schema (e.g., alterations to the structure of the database like adding a column or other tables) should not affect the function of the application (external views).\r\n<h3>Physical data independence<\/h3>\r\n<em>Physical data independence<\/em> refers to the immunity of the internal model to changes in the physical model. The logical schema stays unchanged even though changes are made to file organization or storage structures, storage devices or indexing strategy.\r\n\r\nPhysical data independence deals with hiding the details of the storage structure from user applications. The applications should not be involved with these issues, since there is no difference in the operation carried out against the data.\r\n<div class=\"textbox textbox--key-takeaways\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\">Key Terms<\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n<strong>conceptual model<\/strong>:\u00a0<span>the logical structure of the entire database<\/span>\r\n\r\n<strong>conceptual schema<\/strong>: another term for logical schema\r\n\r\n<strong>data independence<\/strong>:\u00a0the immunity of user\u00a0applications\u00a0to changes made in the definition and organization of data\r\n\r\n<strong>data model<\/strong>:a collection of concepts or notations for describing data, data relationships, data semantics and data constraints\r\n\r\n<strong>data modelling<\/strong>:\u00a0the first step in the process of database design\r\n\r\n<strong>database logical design<\/strong>:\u00a0 defines a database in a data model of a specific database management system\r\n\r\n<strong>database physical design<em>:<\/em><\/strong>\u00a0defines the internal database storage structure, file organization or indexing techniques\r\n\r\n<strong>entity relationship diagram (ERD)<\/strong>: a data model describing the database showing tables, attributes and relationships\r\n\r\n<strong>external model<\/strong>: \u00a0represents the user\u2019s view of the database\r\n\r\n<strong>external schema<\/strong>: user view\r\n\r\n<strong>internal model:<\/strong>\u00a0<span>a representation of the database as seen by the DBMS<\/span>\r\n\r\n<strong>logical data independence<\/strong>: the ability to change the logical schema without changing the external schema\r\n\r\n<strong>logical design<\/strong>: where you create all the tables, constraints, keys, rules, etc.\r\n\r\n<strong>logical schema<\/strong>:\u00a0a\u00a0conceptual design of the database done on paper or a whiteboard, much like architectural drawings for a house\r\n\r\n<strong>operating system (OS)<\/strong>: manages the physical level of the physical model\r\n\r\n<strong>physical data independence<\/strong>: the immunity of the internal model to changes in the physical model\r\n\r\n<strong>physical model<\/strong>:\u00a0<span>the physical representation of the database<\/span>\r\n\r\n<strong>schema<\/strong>: an overall description of a database\r\n\r\n<\/div><\/div>\r\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\">Exercises<\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\n<ol>\r\n \t<li>Describe the purpose of a conceptual design.<\/li>\r\n \t<li>How is a conceptual design different from a logical design?<\/li>\r\n \t<li>What is an external model?<\/li>\r\n \t<li>What is a conceptual model?<\/li>\r\n \t<li>What is an internal model?<\/li>\r\n \t<li>What is a physical model?<\/li>\r\n \t<li>Which model does the database administrator work with?<\/li>\r\n \t<li>Which model does the end user work with?<\/li>\r\n \t<li>What is logical data independence?<\/li>\r\n \t<li>What is physical data independence?<\/li>\r\n<\/ol>\r\nAlso see <em>Appendix A: University Registration Data Model Example<\/em>\r\n\r\n<\/div><\/div>\r\n<h2>Attribution<\/h2>\r\nThis chapter of\u00a0<em>Database Design<\/em>\u00a0is a derivative copy of\u00a0<a href=\"http:\/\/cnx.org\/contents\/b57b8760-6898-469d-a0f7-06e0537f6817@1\">Database System Concepts<\/a>\u00a0by\u00a0Nguyen Kim Anh\u00a0licensed under\u00a0<a href=\"http:\/\/creativecommons.org\/licenses\/by\/3.0\/\">Creative Commons Attribution License 3.0 license<\/a>\r\n\r\nThe following material was written by Adrienne Watt:\r\n<ul>\r\n \t<li style=\"list-style-type: none;\">\r\n<ol>\r\n \t<li>Some or all of the introduction, degrees of data abstraction, data abstraction layer<\/li>\r\n \t<li>Key Terms<\/li>\r\n \t<li>Exercises<\/li>\r\n<\/ol>\r\n<\/li>\r\n<\/ul>","rendered":"<p><em>Data modelling<\/em> is the first step in the process of database design. This step is sometimes considered to be\u00a0a high-level and abstract design phase, <span>also referred to as conceptual design<\/span>. The aim of this phase is\u00a0to describe:<\/p>\n<ul>\n<li>The\u00a0data contained in the database (e.g., entities: students, lecturers, courses, subjects)<\/li>\n<li>The relationships between data items (e.g., students are supervised by lecturers; lecturers teach courses)<\/li>\n<li>The constraints on data (e.g., student number has exactly eight\u00a0digits; a subject has four\u00a0or six\u00a0units of credit only)<\/li>\n<\/ul>\n<p><span>In the second step<\/span>, the data items, the relationships and the constraints are all expressed using the concepts provided by the high-level data model. Because these concmepts do not include the implementation details, the result of the data modelling process is a (semi) formal representation of the database structure. This result is quite easy to understand so it is used as reference to make sure that all the user\u2019s requirements are met.<\/p>\n<p><span>The third step is database design<\/span>. During this step, we might have two sub-steps:\u00a0one called <em>database logical design<\/em>, which defines a database in a data model of a specific DBMS, and another called <em>database physical design<\/em>, which defines the internal database storage structure, file organization or indexing techniques. These two sub-steps\u00a0are database implementation and operations\/user interfaces building steps.<\/p>\n<p>In the database design phases, data are represented using a certain data model. The <em>data model<\/em> is a collection of concepts or notations for describing data, data relationships, data semantics and data constraints. Most data models also include a set of basic operations for manipulating data in the database.<\/p>\n<h2>Degrees of Data Abstraction<\/h2>\n<p>In this section we will look at the database design process in terms of specificity.\u00a0Just as any design starts at a high level and proceeds to an ever-increasing level of detail, so does database design.\u00a0For example, when building a home, you start with how many bedrooms and bathrooms the home will have, whether it\u00a0will be on one level or multiple levels, etc.\u00a0The next step is to get an architect to design the home from a more structured perspective. This level gets more detailed with respect to actual room sizes, how the home will be wired, where the plumbing fixtures will be placed, etc.\u00a0The last step is to hire a contractor to build the home.\u00a0That\u2019s looking at the design from a high level of abstraction to an increasing\u00a0level of\u00a0detail.<\/p>\n<p>The database design is very much like that. It starts with users identifying the business rules; then the database designers and analysts create the database design; and then the database administrator implements the design using a DBMS.<\/p>\n<p>The following subsections summarize the models in order of decreasing level of\u00a0abstraction.<\/p>\n<h3>External models<\/h3>\n<ul>\n<li>Represent the user\u2019s view of the database<\/li>\n<li>Contain multiple different external views<\/li>\n<li>Are\u00a0closely related to the real world as perceived by each user<\/li>\n<\/ul>\n<h3>Conceptual models<\/h3>\n<ul>\n<li>Provide flexible data-structuring capabilities<\/li>\n<li>Present a &#8220;community view&#8221;: the logical structure of the entire database<\/li>\n<li><span>Contain data stored in the database<\/span><\/li>\n<li>Show relationships among data including:\n<ul>\n<li>Constraints<\/li>\n<li>Semantic information (e.g., business rules)<\/li>\n<li>Security and\u00a0integrity information<\/li>\n<\/ul>\n<\/li>\n<li>Consider a database as a collection of entities (objects) of various kinds<\/li>\n<li>Are the basis for identification and high-level description of main data objects; they avoid details<\/li>\n<li>Are database independent regardless of the database you will be using<\/li>\n<\/ul>\n<h3>Internal models<\/h3>\n<p>The three\u00a0best-known models of this kind are the relational data model, the network data model and the hierarchical data model. These internal models:<\/p>\n<ul>\n<li>Consider a database as a collection of fixed-size records<\/li>\n<li>Are\u00a0closer to the physical level or file structure<\/li>\n<li>Are\u00a0a representation of the database as seen by the DBMS.<\/li>\n<li>Require the designer to match the conceptual model\u2019s characteristics and constraints to those of the selected implementation model<\/li>\n<li>Involve mapping the entities in the conceptual model to the tables in the relational model<\/li>\n<\/ul>\n<h3>Physical models<\/h3>\n<ul>\n<li>Are the physical representation of the database<\/li>\n<li>Have the lowest level of abstractions<\/li>\n<li>Are\u00a0how the data is stored; they deal with\n<ul>\n<li>Run-time performance<\/li>\n<li>Storage utilization and\u00a0compression<\/li>\n<li>File organization and\u00a0access methods<\/li>\n<li>Data encryption<\/li>\n<\/ul>\n<\/li>\n<li>Are the physical level \u2013 managed by<span> the <em>operating system<\/em><\/span><em>\u00a0(OS)<\/em><\/li>\n<li>Provide concepts that describe the details of how data are stored in the computer\u2019s memory<\/li>\n<\/ul>\n<h2>Data Abstraction Layer<\/h2>\n<p>In a pictorial view, you can see how the different models work together. Let\u2019s look at this from the highest level, the external model.<\/p>\n<p>The external model is the end user&#8217;s view of the data. Typically a database is an enterprise system that serves the needs of multiple departments. However, one department is not interested in seeing other departments\u2019 data\u00a0(e.g., the\u00a0human resources (HR) department does not care to view the sales department&#8217;s data). Therefore, one user view will differ from another.<\/p>\n<p>The external model requires that the designer subdivide a set of requirements and constraints into functional modules that can be examined within the framework of their external models (e.g., human resources versus sales).<\/p>\n<p>As a data designer, you need to understand all the data so that you can build an enterprise-wide database. Based on the needs of various departments, the conceptual model is the first model created.<\/p>\n<p>At this stage, the conceptual model is independent of both software and hardware. It does not depend on the DBMS software used to implement the model. It does not depend on the hardware used in the implementation of the model. Changes in either hardware or DBMS software have no effect on the database design at the conceptual level.<\/p>\n<p>Once a DBMS is selected, you can then implement it. This is the internal model. Here you create all the tables, constraints, keys, rules, etc.\u00a0 This is often referred to as the <em>logical design<\/em>.<\/p>\n<p>The physical model is simply the way the data is stored on disk. Each database vendor has its\u00a0own way of storing the data.<\/p>\n<figure id=\"attachment_42\" aria-describedby=\"caption-attachment-42\" style=\"width: 300px\" class=\"wp-caption aligncenter\"><a href=\"http:\/\/opentextbc.ca\/dbdesign01\/wp-content\/uploads\/sites\/11\/2013\/12\/Table-Description-300x146.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-42\" alt=\"Three stick figures and the words &quot;End Users&quot; at the top. Under that is a yellow rectangle labelled External Model. Inside the\" src=\"http:\/\/opentextbc.ca\/dbdesign01\/wp-content\/uploads\/sites\/11\/2013\/12\/Data-Abstraction-300x226.jpg\" height=\"226\" width=\"300\" \/><\/a><figcaption id=\"caption-attachment-42\" class=\"wp-caption-text\">Figure 5.1. Data abstraction layers.<\/figcaption><\/figure>\n<h2>Schemas<\/h2>\n<p>A <em>schema<\/em> is an overall description of a database, and it is usually represented by the\u00a0<em>entity relationship diagram (ERD)<\/em>. There are many subschemas that represent external models and thus display external views of the data. Below is a list of items to consider during the design process of a database.<\/p>\n<ul>\n<li>External schemas: there are multiple<\/li>\n<li>Multiple subschemas: these display multiple external views of the data<\/li>\n<li>Conceptual schema: there is only one. This schema includes data items, relationships and\u00a0constraints, all represented in an ERD.<\/li>\n<li>Physical schema: there is only one<\/li>\n<\/ul>\n<h2>Logical and Physical Data Independence<\/h2>\n<p><em>Data independence<\/em> refers to the immunity of user applications to changes made in the definition and organization of data. Data abstractions expose only those items that are important or pertinent to the user. Complexity is hidden from the database user.<\/p>\n<p>Data independence and operation independence together form\u00a0the feature of data abstraction. There are two types of data independence: logical and physical.<\/p>\n<h3>Logical data independence<\/h3>\n<p>A<em> logical schema <\/em>is\u00a0a\u00a0conceptual design of the database done on paper or a whiteboard, much like architectural drawings for a house. The ability to change the logical schema,\u00a0without changing the <span><em>external schema<\/em>\u00a0or user view,\u00a0<\/span>\u00a0is called <em>logical data independence<\/em>. For example, the addition or removal of new entities, attributes or relationships to this <em>conceptual schema<\/em> should be possible without having to change existing external schemas or rewrite existing application programs.\u00a0<em>\u00a0<\/em><\/p>\n<p>In other words, changes to\u00a0the logical schema (e.g., alterations to the structure of the database like adding a column or other tables) should not affect the function of the application (external views).<\/p>\n<h3>Physical data independence<\/h3>\n<p><em>Physical data independence<\/em> refers to the immunity of the internal model to changes in the physical model. The logical schema stays unchanged even though changes are made to file organization or storage structures, storage devices or indexing strategy.<\/p>\n<p>Physical data independence deals with hiding the details of the storage structure from user applications. The applications should not be involved with these issues, since there is no difference in the operation carried out against the data.<\/p>\n<div class=\"textbox textbox--key-takeaways\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\">Key Terms<\/p>\n<\/header>\n<div class=\"textbox__content\">\n<strong>conceptual model<\/strong>:\u00a0<span>the logical structure of the entire database<\/span><\/p>\n<p><strong>conceptual schema<\/strong>: another term for logical schema<\/p>\n<p><strong>data independence<\/strong>:\u00a0the immunity of user\u00a0applications\u00a0to changes made in the definition and organization of data<\/p>\n<p><strong>data model<\/strong>:a collection of concepts or notations for describing data, data relationships, data semantics and data constraints<\/p>\n<p><strong>data modelling<\/strong>:\u00a0the first step in the process of database design<\/p>\n<p><strong>database logical design<\/strong>:\u00a0 defines a database in a data model of a specific database management system<\/p>\n<p><strong>database physical design<em>:<\/em><\/strong>\u00a0defines the internal database storage structure, file organization or indexing techniques<\/p>\n<p><strong>entity relationship diagram (ERD)<\/strong>: a data model describing the database showing tables, attributes and relationships<\/p>\n<p><strong>external model<\/strong>: \u00a0represents the user\u2019s view of the database<\/p>\n<p><strong>external schema<\/strong>: user view<\/p>\n<p><strong>internal model:<\/strong>\u00a0<span>a representation of the database as seen by the DBMS<\/span><\/p>\n<p><strong>logical data independence<\/strong>: the ability to change the logical schema without changing the external schema<\/p>\n<p><strong>logical design<\/strong>: where you create all the tables, constraints, keys, rules, etc.<\/p>\n<p><strong>logical schema<\/strong>:\u00a0a\u00a0conceptual design of the database done on paper or a whiteboard, much like architectural drawings for a house<\/p>\n<p><strong>operating system (OS)<\/strong>: manages the physical level of the physical model<\/p>\n<p><strong>physical data independence<\/strong>: the immunity of the internal model to changes in the physical model<\/p>\n<p><strong>physical model<\/strong>:\u00a0<span>the physical representation of the database<\/span><\/p>\n<p><strong>schema<\/strong>: an overall description of a database<\/p>\n<\/div>\n<\/div>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\">Exercises<\/p>\n<\/header>\n<div class=\"textbox__content\">\n<ol>\n<li>Describe the purpose of a conceptual design.<\/li>\n<li>How is a conceptual design different from a logical design?<\/li>\n<li>What is an external model?<\/li>\n<li>What is a conceptual model?<\/li>\n<li>What is an internal model?<\/li>\n<li>What is a physical model?<\/li>\n<li>Which model does the database administrator work with?<\/li>\n<li>Which model does the end user work with?<\/li>\n<li>What is logical data independence?<\/li>\n<li>What is physical data independence?<\/li>\n<\/ol>\n<p>Also see <em>Appendix A: University Registration Data Model Example<\/em><\/p>\n<\/div>\n<\/div>\n<h2>Attribution<\/h2>\n<p>This chapter of\u00a0<em>Database Design<\/em>\u00a0is a derivative copy of\u00a0<a href=\"http:\/\/cnx.org\/contents\/b57b8760-6898-469d-a0f7-06e0537f6817@1\">Database System Concepts<\/a>\u00a0by\u00a0Nguyen Kim Anh\u00a0licensed under\u00a0<a href=\"http:\/\/creativecommons.org\/licenses\/by\/3.0\/\">Creative Commons Attribution License 3.0 license<\/a><\/p>\n<p>The following material was written by Adrienne Watt:<\/p>\n<ul>\n<li style=\"list-style-type: none;\">\n<ol>\n<li>Some or all of the introduction, degrees of data abstraction, data abstraction layer<\/li>\n<li>Key Terms<\/li>\n<li>Exercises<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n","protected":false},"author":1,"menu_order":5,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["adrienne-watt"],"pb_section_license":""},"chapter-type":[],"contributor":[47],"license":[],"class_list":["post-36","chapter","type-chapter","status-publish","hentry","contributor-adrienne-watt"],"part":3,"_links":{"self":[{"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/pressbooks\/v2\/chapters\/36","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":26,"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/pressbooks\/v2\/chapters\/36\/revisions"}],"predecessor-version":[{"id":1142,"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/pressbooks\/v2\/chapters\/36\/revisions\/1142"}],"part":[{"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/pressbooks\/v2\/chapters\/36\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/wp\/v2\/media?parent=36"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/pressbooks\/v2\/chapter-type?post=36"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/wp\/v2\/contributor?post=36"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/opentextbc.ca\/dbdesign01\/wp-json\/wp\/v2\/license?post=36"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}