Embed Size (px)
DESCRIPTION
Database Management System 1
Citation preview
A database model is a theory or specification describing how a database is structured and used.
Also known as Database Schema Schemas are generally stored in a data dictionary and often used to refer to a
graphical depiction of the database structure.
It also defines a set of operations that can be performed on the data.
1. Hierarchical Model
2. Network Model
3. Relational Model
4. Entity-Relationship Model5. Object-Relational Model
6. Object Model
1. Flat Model
2. Associative Model
3. Concept-Oriented Model
4. Entity-Attribute-Value Model5. Information Model
6. Multi-Dimensional Model7. Semantic Data Model8. Semi-Structure Model9. Star Schema Model10. XML Database Model11. Context Model
A hierarchical data model is a data model in which the data is organized into a tree-like structure.
All attributes of a specific record are listed under an entity type.
An entity type is the equivalent of a table.Each individual record is represented as a row and an
attribute as a column.
Entity types are related to each other using 1: N mapping, also known as one-to-many relationships.
IMS is the most recognized and used hierarchical database developed by IBM.
An organization had records of employees in a table (entity type) called "Employees". In the table there would be attributes/columns such as First Name, Last Name, Job Name and Wage. The company also has data about the employee’s children in a separate table called "Children" with attributes such as First Name, Last Name, and date of birth. The Employee table represents a parent segment and the Children table represents a Child segment. These two segments form a hierarchy where an employee may have many children, but each child may only have one parent.
EmpNo DesignationReportsT
o
10 Director
20 Senior Manager 10
30 Typist 20
40 Programmer 20
• When the Primary Key as a common field, it is called a foreign key in the second table.
A tree structure is a way of representing the hierarchical nature of a structure in a graphical form.
It is named a "tree structure" because the classic representation looks a bit like a tree, even though the tree is generally shown upside down compared with a real tree; that is to say with the root at the top and the leaves at the bottom.
A tree structure showing the possible hierarchical organization of an encyclopedia.
1. Internet: Usenet hierarchy, Document Object Model's logical structure, Yahoo! subject index, Open Directory Project
2. Information management: Dewey Decimal System
3. Management: hierarchical organizational structures
4. Computer Science: binary search tree Red-Black Tree AVL tree
5. Biology: evolutionary tree
6. Business: pyramid selling scheme
7. Project management: work breakdown structure
8. Linguistics (syntax): Phrase structure trees
There are many ways of visually representing tree structures. Almost always, these boil down to variations, or combinations, of a few basic styles:
1. Classical node-link diagrams
2. Nested sets
3. Layered "icicle" diagrams
4. Outlines and tree views 5. Nested parentheses
Classical node-link diagrams, that connect nodes together with line segments:
encyclopedia / \ science culture / \ art craft
Nested sets that use enclosure/containment to show parenthood
+------encyclopedia------+ | +--culture--+ | | science |art craft| | | +-----------+ | +------------------------+
Layered "icicle" diagrams that use alignment/adjacency:
+-------------------+ | encyclopedia | +---------+---------+ | science | culture | +---------+---+-----+ |art|craft| +---+-----+
Lists or diagrams that use indentation, sometimes called "outlines" or "tree views":
encyclopedia science culture art craft
Nested parentheses, a correspondence first noticed by Sir Arthur Cayley
science, ((art, craft)culture)encyclopedia
A hierarchical query is a type of SQL query that handles hierarchical model data.
Standard SQL specifies hierarchical queries by way of recursive common table expressions (CTEs). Recursive CTEs are supported by systems including IBM DB2, Microsoft SQL Server, Firebird 2.1and PostgreSQL 8.4.
An alternative syntax is the non-standard CONNECT BY construct. "CONNECT BY" is supported by EnterpriseDB and Oracle database.
SELECT select_listFROM table_expression[ WHERE ... ][ START WITH start_expression ]CONNECT BY { PRIOR parent_expr = child_expr | child_expr = PRIOR parent_expr }[ ORDER SIBLINGS BY column1 [ ASC | DESC ] [, column2 [ ASC | DESC ] ] ...[ GROUP BY ... ][ HAVING ... ]...
SELECT LEVEL, LPAD (' ', 2 * (LEVEL - 1)) || ename "employee", empno, mgr FROM emp START WITH mgr IS NULL CONNECT BY PRIOR empno = mgr;
level | employee | empno | mgr-------+-------------+-------+------ 1 | KING | 7839 | 2 | JONES | 7566 | 7839 3 | SCOTT | 7788 | 7566 4 | ADAMS | 7876 | 7788 3 | FORD | 7902 | 7566 4 | SMITH | 7369 | 7902 2 | BLAKE | 7698 | 7839 3 | ALLEN | 7499 | 7698 3 | WARD | 7521 | 7698 3 | MARTIN | 7654 | 7698 3 | TURNER | 7844 | 7698 3 | JAMES | 7900 | 7698 2 | CLARK | 7782 | 7839 3 | MILLER | 7934 | 7782(14 rows)
The output of the query would look like:
The network model is a database model conceived as a flexible way of representing objects and their relationships.
The network model organizes data using two fundamental constructs, called records and sets.
Records contain fields (which may be organized hierarchically, as in the programming language COBOL)
Sets (not to be confused with mathematical sets) define one-to-many relationships between records: one owner, many members.
The network model is a variation on the hierarchical model.
The operations of the network model are navigational in style: a program maintains a current position, and navigates from one record to another by following the relationships in which the record participates.
Records can also be located by supplying key values.
1. TurboIMAGEIMAGE is the primary reason that the HP3000 was a success. It is a reliable, simple, fast database for MPE. After about a decade of enhancements it was renamed TurboIMAGE, then TurboIMAGE/XL after the PA-RISC migration. Programs can access and update records using IMAGE intrinsics. Today it is known as IMAGE/SQL because it includes an SQL (Structured Query Language) frontend and client-server support for PC accessors.
2. IDMS(Integrated Database Management System)IDMS (Integrated Database Management System) is a (network) CODASYL database management system first developed at B.F. Goodrich and later marketed by Cullinane Database Systems (renamed Cullinet in 1983). Since 1989 the product has been owned by Computer Associates, who renamed it CA-IDMS.
3. RDM EmbeddedRDM Embedded (for Raima Database Manager) is a high performing ACID-compliant embedded database management library designed for both disk based and in-memory embedded systems and applications. RDM Embedded can run purely in main memory (also known as an in-memory database, or IMDB), purely on disk, or in mixed mode storing parts of the dataset in-memory and parts on-disk. RDM Embedded has a proven track record first released in 1984 counting over 25,000,000 installations in all kinds of embedded systems and applications.
4. RDM ServerRDM Server is ACID-compliant client/server embedded database system designed for both disk based and in-memory embedded systems and applications.
A database based on the relational model developed by E.F. Codd.
Relational database allows the definition of data structures, storage and retrieval operations and integrity constraints.
A database the data and relations between them are organized in tables.
A table is a collection of records and each record in a table contains the same fields.
1. Values are atomic
2. Each row is unique
3. Column values of the same kind
4. The sequence of column is insignificant
5. The sequence of row is insignificant
6. Each column has a unique name
This property implies that columns in a relational table are not repeating group or arrays.
Such tables are referred to as being in the "first normal form" (1NF).
The atomic value property of relational tables is important because it is one of the cornerstones of the relational model.
The key benefit of the one value property is that it simplifies data manipulation logic.
This property ensures that no two rows in a relational table are identical.
There is at least one column, or set of columns, the values of which uniquely identify each row in the table.
Such columns are called primary keys.This property guarantees that every row in a relational
table is meaningful and that a specific row can be identified by specifying the primary key value.
In relational terms this means that all values in a column come from the same domain.
A domain is a set of values which a column may have. This property simplifies data access because developers and users can be certain of the type of data contained in a given column.
It also simplifies data validation. Because all values are from the same domain, the domain
can be defined and enforced with the Data Definition Language (DDL) of the database software.
This property states that the ordering of the columns in the relational table has no meaning.
Columns can be retrieved in any order and in various sequences.
It enables many users to share the same table without concern of how the table is organized.
It also permits the physical structure of the database to change without affecting the relational tables.
This property is analogous the one above but applies to rows instead of columns.
Adding information to a relational table is simplified and does not affect existing queries.
Adding information to a relational table is simplified and does not affect existing queries.
Because the sequence of columns is insignificant, columns must be referenced by name and not by position.
A column name need not be unique within an entire database but only within the table to which it belongs.
Example of Relational Model
An object-relational database (ORD), or object-relational database management system (ORDBMS), is a database management system (DBMS) similar to a relational database
An object-oriented database model: objects, classes and inheritance are directly supported in database schemas and in the query language.
It supports extension of the data model with custom data-types and methods.
An object-relational database can be said to provide a middle ground between relational databases and object-oriented databases (OODBMS).
In object-relational databases, the approach is essentially that of relational databases: the data resides in the database and is manipulated collectively with queries in a query language;
at the other extreme are OODBMSes in which the database is essentially a persistent object store for software written in an object-oriented programming language, with a programming API for storing and retrieving objects, and little or no specific support for querying.
Example of Object-Relational Model
In computing, object model has two related but distinct meanings:
1. The properties of objects in general, in a specific computer programming language, technology, notation or methodology that uses them. For example, the Java object model, the COM object model, or the object model of OMT. Such object models are usually defined using concepts such as class, message, inheritance, polymorphism, and encapsulation. There is an extensive literature on formalized object models as a subset of the formal semantics of programming languages.
2. A collection of objects or classes through which a program can examine and manipulate some specific parts of its world. In other words, the object-oriented interface to some service or system. Such an interface is said to be the object model of the represented service or system. For example, the Document Object Model (DOM) is a collection of objects that represent a page in a web browser, used by script programs to examine and dynamically change the page. There is a Microsoft Excel object model for controlling Microsoft Excel from another program, and the ASCOM Telescope Driver is an object model for controlling an astronomical telescope.
Example of Object Model for Paint Application
The Entity-Relationship (ER) model was originally proposed by Peter in 1976 [Chen76] as a way to unify the network and relational database views
ER model is a conceptual data model that views the real world as entities and relationships.
A basic component of the model is the Entity-Relationship diagram which is used to visually represent data objects.
It maps well to the relational model. The constructs used in the ER model can easily be transformed into relational tables.
It is simple and easy to understand with a minimum of training. Therefore, the model can be used by the database designer to communicate the design to the end user.
In addition, the model can be used as a design plan by the database developer to implement a data model in specific database management software.
The ER model views the real world as a construct of entities and association between entities.
1. Entities
2. Special Entity Types
3. Attributes
4. Relationships
5. Classifying Relationships 6. Degree of a Relationship 7. Connectivity and Cardinality 8. Direction
9. Type
10. Existence
11. Generalization Hierarchies
12. ER Notation
Entities are the principal data object about which information is to be collected.
Entities are usually recognizable concepts, either concrete or abstract, such as person, places, things, or events which have relevance to the database.
Entities are classified as independent or dependent (in some methodologies, the terms used are strong and weak, respectively).
An independent entity is one that does not rely on another for identification.
A dependent entity is one that relies on another for identification.
An entity occurrence (also called an instance) is an individual occurrence of an entity.
An occurrence is analogous to a row in the relational table.
Associative entities (also known as intersection entities) are entities used to associate two or more entities in order to reconcile a many-to-many relationship.
Subtypes entities are used in generalization hierarchies to represent a subset of instances of their parent entity, called the supertype, but which have attributes or relationships that apply only to the subset.
A Relationship represents an association between two or more entities.
An example of a relationship would be:
employees are assigned to projects
projects have subtasks
departments manage one or more projects
Relationships are classified in terms of degree, connectivity, cardinality, and existence.
Attributes describe the entity of which they are associated.
A particular instance of an attribute is a value. For example, "Jane R. Hathaway" is one value of the attribute Name.
The domain of an attribute is the collection of all possible values an attribute can have. The domain of Name is a character string.
Attributes can be classified as identifiers or descriptors.
Identifiers, more commonly called keys, uniquely identify an instance of an entity.
A descriptor describes a non-unique characteristic of an entity instance.
Relationships are classified by their degree, connectivity, cardinality, direction, type, and existence.
Not all modeling methodologies use all these classifications.
The degree of a relationship is the number of entities associated with the relationship.
The n-ary relationship is the general form for degree n. Special cases are the binary, and ternary, where the degree is 2, and 3, respectively.
Binary relationships, the association between two entities is the most common type in the real world.
A recursive binary relationship occurs when an entity is related to itself. An example might be "some employees are married to other employees".
A ternary relationship involves three entities and is used when a binary relationship is inadequate.
Many modeling approaches recognize only binary relationships.
Ternary or n-ary relationships are decomposed into two or more binary relationships.
The connectivity of a relationship describes the mapping of associated entity instances in the relationship.
The values of connectivity are "one" or "many". The cardinality of a relationship is the actual number of related occurrences for each of the two entities.
The basic types of connectivity for relations are: one-to-one, one-to-many, and many-to-many.
A one-to-one (1:1) relationship is when at most one instance of a entity A is associated with one instance of entity B. For example, "employees in the company are each assigned their own office. For each employee there exists a unique office and for each office there exists a unique employee.
A one-to-many (1:N) relationships is when for one instance of entity A, there are zero, one, or many instances of entity B, but for one instance of entity B, there is only one instance of entity A. An example of a 1:N relationships is
a department has many employees each employee is assigned to one department
A many-to-many (M:N) relationship, sometimes called non-specific, is when for one instance of entity A, there are zero, one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A. An example is: employees can be assigned to no more than two projects at the same time; projects must have assigned at least three employees
The direction of a relationship indicates the originating entity of a binary relationship.
The entity from which a relationship originates is the parent entity; the entity where the relationship terminates is the child entity.
The direction of a relationship is determined by its connectivity.
In a one-to-one relationship the direction is from the independent entity to a dependent entity.
If both entities are independent, the direction is arbitrary. With one-to-many relationships, the entity occurring once is the parent.
The direction of many-to-many relationships is arbitrary.
An identifying relationship is one in which one of the child entities is also a dependent entity.
A non-identifying relationship is one in which both entities are independent.
Existence denotes whether the existence of an entity instance is dependent upon the existence of another, related, entity instance.
The existence of an entity in a relationship is defined as either mandatory or optional.
If an instance of an entity must always occur for an entity to be included in a relationship, then it is mandatory. An example of mandatory existence is the statement "every project must be managed by a single department".
If the instance of the entity is not required, it is optional. An example of optional existence is the statement, "employees may be assigned to work on projects".
A generalization hierarchy is a form of abstraction that specifies that two or more entities that share common attributes can be generalized into a higher level entity type called a supertype or generic entity.
The lower-level of entities become the subtype, or categories, to the supertype. Subtypes are dependent entities.
Generalization occurs when two or more entities represent categories of the same real-world object.
For example, Wages_Employees and Classified_Employees represent categories of the same entity, Employees. In this example, Employees would be the supertype; Wages_Employees and Classified_Employees would be the subtypes.
Subtypes can be either mutually exclusive (disjoint) or overlapping (inclusive).
A mutually exclusive category is when an entity instance can be in only one category.
An overlapping category is when an entity instance may be in two or more subtypes. An example would be a person who works for a university could also be a student at that same university.
The completeness constraint requires that all instances of the subtype be represented in the supertype.
Generalization hierarchies can be nested. That is, a subtype of one hierarchy can be a supertype of another. The level of nesting is limited only by the constraint of simplicity. Subtype entities may be the parent entity in a relationship but not the child.
There is no standard for representing data objects in ER diagrams. Each modeling methodology uses its own notation.
The original notation used by Chen is widely used in academics texts and journals but rarely seen in either CASE tools or publications by non-academics.
Today, there are a number of notations used; among the more common are Bachman, crow's foot, and IDEFIX.
All notational styles represent entities as rectangular boxes and relationships as lines connecting boxes.
Each style uses a special set of symbols to represent the cardinality of a connection.
The symbols used for the basic ER constructs are:
1. Entities are represented by labeled rectangles. The label is the name of the entity. Entity names should be singular nouns.
2. Relationships are represented by a solid line connecting two entities. The name of the relationship is written above the line. Relationship names should be verbs.
3. Attributes, when included, are listed inside the entity rectangle. Attributes which are identifiers are underlined. Attribute names should be singular nouns.
4. Cardinality of many is represented by a line ending in a crow's foot. If the crow's foot is omitted, the cardinality is one.
5. Existence is represented by placing a circle or a perpendicular bar on the line. Mandatory existence is shown by the bar (looks like a 1) next to the entity for an instance is required. Optional existence is shown by placing a circle next to the entity that is optional.
Example of ER Notation
