Data Models PDF - Strathmore University 2024

Strathmore University | 2024 DATA MODELS Database Systems  INTRODUCTION Data models are a description of the structure/organization of a database. Structure of the database involves : Data contained in the database and their data types Relationship between...

Strathmore University | 2024 DATA MODELS Database Systems  INTRODUCTION Data models are a description of the structure/organization of a database. Structure of the database involves : Data contained in the database and their data types Relationship between data items: eg students are supervised by lecturers, lecturers teach courses Constraints on the data eg student number has eight digits The purpose of a data model is to represent data and to make the data understandable Page 1  COMPONENTS 1. a structural part, consisting of a set of rules according to which databases can be constructed; 2. a manipulative part, defining the types of operation that are allowed on the data. This includes the operations that are used for updating or retrieving data from the database and for changing the structure of the database; 3. possibly a set of integrity constraints, which ensures that the data is accurate Page 2  DATA MODEL CATEGORIES In database design phases, data are represented using a certain data model. Data models fall into three broad categories: Object-based models Record-based models Physical data models. The first two are used to describe data at the conceptual and external levels, the latter is used to describe data at the internal level Page 3 OBJECT BASED MODELS Object-based data models use concepts such as entities, attributes, and relationships. An entity is a distinct object (a person, place, thing, concept, event) in the organization that is to be represented in the database. An attribute is a property that describes some aspect of the object that we wish to record, and a relationship is an association between entities Page 4  PHYSICAL BASED MODELS Physical data models describe how data is stored in the computer, representing information such as record structures, record orderings, and access paths. There are not as many physical data models as logical data models, the most common ones being the unifying model and the frame memory. Page 5 RECORD BASED MODELS There are three principal types of record-based logical data model: Relational data model Network data model Hierarchical data model. Page 6 RELATIONAL DATA MODEL Data and relationships are represented as tables, each of which has a number of columns with a unique name. Page 7 NETWORK DATA MODEL Data is represented as collections of records, and relationships are represented by sets. Compared with the relational model, relationships are explicitly modeled by the sets, which become pointers in the implementation. Entities are organized in a graph, in which some entities can be accessed through several paths Page 8 HIERARCHICAL DATA MODEL Data is represented as collections of records and relationships are represented by sets. However, the hierarchical model allows a node to have only one parent. A hierarchical model can be represented as a tree graph, with records appearing as nodes (also called segments) and sets as edges Page 9  ANY QUESTIONS  MULTIUSER DBMS ARCHITECTURES The common architectures that are used to implement multi-user database management systems include: Teleprocessing File-Server Client-Server Page 1  TELEPROCESSING One computer with a single CPU and a number of terminals. Processing performed within the same physical computer. User terminals are typically “dumb”, incapable of functioning on their own, and cabled to the central computer.. Page 3  FILE SERVER ARCHITECTURE In a file-server environment, the processing is distributed about the network, typically a local area network (LAN) The file-server holds the files required by the applications and the DBMS. However, the applications and the DBMS run on each workstation, requesting files from the file-server when necessary. The file-server acts simply as a shared hard disk drive. Page 3 File Server Architecture DISADVANTAGES 01 There is a large amount of network traffic. 02 A full copy of the DBMS is required on each workstation. Concurrency, recovery, and integrity control are more complex 03 because there can be multiple DBMSs accessing the same files. Page 4  CLIENT SERVER ARCHITECTURE As the name suggests, there is a client process, which requires some resource, and a server, which provides the resource. The client (tier 1) is primarily responsible for the presentation of data to the user, and the server (tier 2) is primarily responsible for supplying data services to the client. Page 3  TWO TIER ARCHITECTURE Client (tier 1) manages user interface and runs applications. Server (tier 2) holds database and DBMS. Page 3  THREE TIER ARCHITECTURE A new variation of the traditional two-tier client–server model appeared to solve the problem of enterprise scalability. This new architecture proposed three layers, each potentially running on a different platform The user interface layer, which runs on the end-user’s computer (the client). The business logic and data processing layer. This middle tier runs on a server and is often called the application server. A DBMS, which stores the data required by the middle tier. This tier may run on a separate server called the database server. Page 3  THREE TIER ARCHITECTURE Page 3 3 tier architecture ADVANTAGES 01 The need for less expensive hardware because the client is ‘thin’. The added modularity makes it easier to modify or replace one tier 02 without affecting the other tiers. Load balancing is easier with the separation of the core business 03 logic from the database functions. Page 4 3 tier architecture ADVANTAGES Application maintenance is centralized with the transfer of the 04 business logic for many end-users into a single application server. This eliminates the concerns of software distribution that are problematic in the traditional two-tier client–server model. Page 4  ANY QUESTIONS  RELATIONAL MODEL The relational model is the most widely used data model It describes a collection of inter-related relations (or tables) RELATION A relation is a table in a database with columns and rows In the relational model, relations are used to hold information about the objects to be represented in the database. A relation is represented as a two-dimensional table in which the rows of the table correspond to individual records and the table columns correspond to attributes. Page 11  RELATIONAL MODEL ATTRIBUTE An attribute is a named column of a relation. For example, the information on branch offices is represented by the Branch relation, with columns for attributes branchNo (the branch number), street, city, and postcode. TUPLE A tuple is a row of a relation. For example, the rows or records entered in a table form the tuples. These are the individual records. Page 5 RELATIONAL MODEL Page 3  RELATIONAL MODEL DEGREE The degree of a relation is the number of attributes it contains A relation with only one attribute would have degree one and be called a unary relation, two attributes is called binary, one with three attributes is called ternary, and after that the term n-ary is usually used. CARDINALITY The cardinality of a relation is the number of tuples it contains. This changes as tuples are added or deleted. Page 5 RELATIONAL MODEL Page 3  DOMAIN Domain is the set of allowable values for one or more attributes It allows the user to define in a central place the meaning and source of values that attributes can hold. Page 3  ALTERNATE TERMINOLOGY Page 3 Relational Model PROPERTIES OF A RELATION 01 A relation and an attribute must have a distinct name; Each cell of the relation contains exactly one atomic (single) 02 value; The order of attributes does not matter; 03 Page 4 Relational Model PROPERTIES OF A RELATION 04 The values of an attribute are all from the same domain; 05 Each tuple is distinct; there are no duplicate tuples The order of tuples has no significance, theoretically. (However, in 06 practice, the order may affect the efficiency of accessing tuples.) Page 4  RELATIONAL KEYS There are no duplicate tuples within a relation, hence we need to identify one or more attributes uniquely. These attributes are referred to as relational keys There are various types of keys CANDIDATE An attribute, or set of attributes, in a relation that can uniquely identify any tuple without referring to any other data Each relation may have one or more candidate keys A special candidate key is the primary key Page 3  TYPES OF KEYS PRMARY FOREIGN COMPOSITE The candidate key that is An attribute, or set of A set of multiple attributes selected to identify tuples attributes, within one relation that help us uniquely identify uniquely within the relation. that matches a relational every tuple present in a table. key of another relation The attributes present in a set Candidate keys that are not may not be unique whenever selected to be the primary key we consider them separately. are called alternate keys Thus, when we take them all together, it will ensure total uniqueness. Page 6  INTEGRITY CONSTRAINTS Every attribute has an associated domain, and there are constraints (called domain constraints) that form restrictions on the set of values allowed for the attributes of relations. Integrity rules, are constraints or restrictions that apply to all instances of the database NULL A null can be taken to mean the logical value ‘unknown’. It can mean that a value is not applicable to a particular tuple, or it could merely mean that no value has yet been supplied. For example, in the Viewing relation, the comment attribute may be undefined until the potential renter has visited the property and returned his or her comment to the agency. Page 3 Fauget University | 2024 TYPES OF CONSTRAINTS ENTITY INTEGRITY This applies to the primary key attribute In a relation, no attribute of a primary key can be null REFERENTIAL INTEGRITY If a foreign key exists in a relation, either the foreign key value must match a candidate key value of some tuple in its home relation or the origin key value must be wholly null. Page 9  CONSTRAINTS GENERAL CONSTRAINTS Additional rules specified by the users or database administrators of a database that define or constrain some aspect of the enterprise. Example: A user may place an upper limit of 20 upon the number of staff that may work at a branch office, as a general constraint that must be enforced by the DBMS In this case a branch should not be assigned more than 20 staff members Page 9 THANK YOU