FANDOM


Project EE/06/B/FPP-169000

Learning Materials for Information Technology Professionals (EUCIP-Mat)


DATA MANAGEMENT AND DATABASES


1. Number of study hours: 30 2. Short description of the course: This module will expand upon retaining and processing data and information with tools offered by information technology. Significant attention is given to relational databases. Module will also give answers to the following questions: a) What is a data and what is information; b) What is a database; c) Which functional requirements must meet the data stored in database in order to assure that stored data is of a good quality and usable. d) Which data models are in use; e) How to store and use the data in files; f) What is a database management system; g) What is a data warehouse and data mining; h) Main options of SQL query language; i) How to administrate databases; j) How to assure secure database and consistent data. 3. Target groups: Module target groups are first of all vocational education students who specialize on information technology, but it is also an interest of those who simply wish to pass the respective qualifying examination. 4. Prerequisites Passing through the module do not presuppose from student any former knowledge from the field of information technology. 5. Aim of the course - learning outcomes After passing through the module the student knows how to process the data and information on PC, which requirements must the databases meet and how to operate data with SQL query language.

6. B.2 Data management and databases

B.2.1 Data and transactions

B.2.1.1 Information, data and transaction processing

Information – is knowledge about facts, events, things, processes, ideas, definitions or other objects, which have a special meaning in certain context. Information needed in organization is mainly kept in documents (digitally or on paper); data is usually stored in databases. Information can be defined as a message that is given through the communication in a form of a document or audio. As every message, information also has a sender and a receiver. Information has to influence receivers’ estimations and behaviour. Information, differentially from the data, has a meaning, importance and aim. Data transforms into information, if data creator adds meaning to data. It is important to mark that information technology helps to transform data into information and add hereto the value. At the same time information technology does not help with creating the context (categories, calculations, form) – this is created by human beings. Data is an understandably formalized information (for the human being and/or machine), which can be used for communication, interpretation, storing and processing.

Data reflect the detailed and objective facts about the event. All organizations need data and majority of different subject fields are based on data. Effective data management is one of the most important success criterions, which we on the contrary cannot necessarily say about the huge set of data. It is not possible to conclude an automatic objectively accurate decision based on huge set of data for two reasons. First of all, too huge set of data makes it too difficult to identify the data and sort out its’ importance. Secondly, (which is also the main reason), data does not inherently have the meaning. Data characterizes the events that have happened, but it does not include any estimation nor inspiration to it. However, data is important for the organization, because based on that, the information is created. In given context the undividable data unit is called a data element. Nowadays, data are often handled by transaction processing and reporting systems.

Transaction processing is information processing that is divided into individual, indivisible operations, called transactions. Each transaction must succeed or fail as a complete unit; it cannot remain in an intermediate state.

For example, consider a typical banking transaction that involves moving $100 from a customer's savings account to a customer's checking account. This transaction is a single operation in the eyes of the bank, but it involves at least two separate operations in computer terms: debiting the savings account by $100, and crediting the checking account by $100. If the debit operation succeeds but the credit does not (or vice versa), the books of the bank will not balance at the end of the day. There must therefore be a way to ensure that either both operations succeed or both fail, so that there is never any inconsistency in the bank's database as a whole. Transaction processing is designed to provide this.

B.2.1.2 Atomicity, consistency, isolation and durability

ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties that guarantee that database transactions are processed reliably. In the context of databases, a single logical operation on the data is called a transaction

Atomicity refers to the ability of the DBMS to guarantee that either all of the tasks of a transaction are performed or none of them are. For example, the transfer of funds can be completed or it can fail for a multitude of reasons, but atomicity guarantees that one account won't be debited if the other is not credited.

Consistency property ensures that the database remains in a consistent state before the start of the transaction and after the transaction is over (whether successful or not).

Isolation refers to the ability of the application to make operations in a transaction appear isolated from all other operations. This means that no operation outside the transaction can ever see the data in an intermediate state; for example, a bank manager can see the transferred funds on one account or the other, but never on both—even if he runs his query while the transfer is still being processed. More formally, isolation means the transaction history (or schedule) is serializable. This ability is the constraint, which is most frequently relaxed for performance reasons.

Durability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. This means it will survive system failure, and that the database system has checked the integrity constraints and won't need to abort the transaction. Many databases implement durability by writing all transactions into a log that can be played back to recreate the system state right before the failure. A transaction can only be deemed committed after it is safely in the log.

It is difficult to guarantee ACID properties in a network environment. Network connections might fail, or two users might want to use the same part of the database at the same time. Two-phase commit is typically applied in distributed transactions to ensure that each participant in the transaction agrees on whether the transaction should be committed or not.

B.2.1. 3 Issues in designing and maintaining multi-user systems Nowadays most of the databases are multi-user systems, allowing the access to the same data to many users. This concept involves several kind of problems discussed below.

Database concurrency controls ensure that transactions occur in an ordered fashion. The main job of these controls is to protect transactions issued by different users/applications from the effects of each other. They must preserve the four characteristics of database transactions: atomicity, isolation, consistency and durability.

Situation where duplicated data exists in database is called data redundancy For example, in the case of student’s data of college’s database, it is not necessary to write the college’s name and address behind each student’s name. Otherwise the same data will repeat thousands of time. Data availability is a timely and convenient availability and usability of information by the authorized persons and subjects. Availability is usually one of the most important quality indication – worse that can happen to the data is the fact, that data is not accessable (for the authorized persons). Examples about availability problems: • Student gets diploma twice (population register is not usable); • Two married persons are getting married (authorized person of marital status department can not access population register) Data integrity is data deriving from authentic source and ensuring that data is not transformed and/or is not transformed unauthorized thereafter. Data is usually connected to its creator, creating time, context etc. Corrupting those connections can cause unpredictable consequences. Examples about integrity corruptions: • Hacker who has invaded to State Gazete database can change laws according to it’s will; • Prisoners get out of prison before the due date, because of the accidental changes in crime register. Data confidentiality is data accessibility for authorized persons only (and inaccessibility for everyone else). Example about confidentiality violations: • Information about the patients of Tartu University Hospital got into internet; • Ministry of Defence official lost memory stick and confidential information got into private persons’ hand. Data security is the means of ensuring that data is kept safe from corruption and that access to it is suitably controlled. Thus data security helps to ensure privacy. It also helps in protecting personal data

B.2.2 Files and databases

B.2.2.1 File management system and a database management system (DBMS)

File management system

A computer file is a block of arbitrary information, or resource for storing information, which is available to a computer program and is usually based on some kind of durable storage. A file is durable in the sense that it remains available for programs to use after the current program has finished. Computer files can be considered as the modern counterpart of paper documents, which traditionally were kept in offices' and libraries' files, which are the source of the term.

The specific way files are stored on a disk is called a file system, and enables files to have names and attributes. It also allows them to be stored in a hierarchy of directories or folders arranged in a directory tree.

The term computer file management refers to the manipulation of documents and data in files on a computer. Specifically, one may create a new file or edit an existing file and save it; open or load a pre-existing file into memory; or close a file without saving it. Additionally, one may group related files in directories or folders. These tasks are accomplished in different ways in different operating systems and depend on the user interface design and, to some extent, the storage medium being used.

Early operating systems generally supported a single type of disk drive and only one kind of file system. Early file systems were limited in their capacity, speed, and in the kinds of file names and directory structures they could use. These limitations often reflected limitations in the operating systems they were designed for, making it very difficult for an operating system to support more than one file system.

While many simpler operating systems support a limited range of options for accessing storage systems, more modern operating systems like UNIX and Linux support a technology known as a virtual file system or VFS. A modern operating system like UNIX supports a wide array of storage devices, regardless of their design or file systems to be accessed through a common application-programming interface (API). This makes it unnecessary for programs to have any knowledge about the device they are accessing. A VFS allows the operating system to provide programs with access to an unlimited number of devices with an infinite variety of file systems installed on them through the use of specific device drivers and file system drivers.

A connected storage device such as a hard drive will be accessed through a device driver. The device driver understands the specific language of the drive and is able to translate that language into a standard language used by the operating system to access all disk drives.

A file system driver is used to translate the commands used to access each specific file system into a standard set of commands that the operating system can use to talk to all file systems. Programs can then deal with these file systems on the basis of filenames, and directories/folders, contained within a hierarchical structure. They can create, delete, open, and close files, as well as gather various information about them, including access permissions, size, free space, and creation and modification dates.

Various differences between file systems make supporting all file systems difficult. Allowed characters in file names, case sensitivity, and the presence of various kinds of file attributes make the implementation of a single interface for every file system a daunting task. While UNIX and Linux systems generally have support for a wide variety of file systems, proprietary operating systems such a Microsoft Windows tend to limit the user to using a single file system for each task. For example the Windows operating system can only be installed on NTFS, and CDs and DVDs can only be recorded using UDF or ISO 9660

ISO 9660 is a standard published by the International Organization for Standardization (ISO), defines a file system for CD-ROM media. It aims at supporting different computer operating systems such as Windows, classic Mac OS, and Unix-like systems, so that data may be exchanged.

The Universal Disk Format (UDF) is a format specification of a file system for storing files on optical media. It is an implementation of the ISO/IEC 13346 standard (also known as ECMA-167). It is considered to be a replacement of ISO 9660, and today is widely used for (re)writable optical media.

Database management system

Computer program, which keeps the data, receives users’ queries and gives out the data based on the query (if the data exists in database), is called database management system (DBMS).

A DBMS is a complex set of software programs that controls the organization, storage, management, and retrieval of data in a database. DBMS are categorized according to their data structures or types, some time DBMS is also known as Data base Manager. It is a set of prewritten programs that are used to store, update and retrieve a Database. A DBMS includes:

1. A modeling language to define the schema of each database hosted in the DBMS, according to the DBMS data model. • The four most common types of organizations are the hierarchical, network, relational and object models. Inverted lists and other methods are also used. A given database management system may provide one or more of the four models. The optimal structure depends on the natural organization of the application's data, and on the application's requirements (which include transaction rate (speed), reliability, maintainability, scalability, and cost). • The dominant model in use today is the ad hoc one embedded in SQL (Structured Query Language – unified query language used in most DBMS-s), despite the objections of purists who believe this model is a corruption of the relational model, since it violates several of its fundamental principles for the sake of practicality and performance. Many DBMSs also support the Open Database Connectivity API that supports a standard way for programmers to access the DBMS. 2. Data structures (fields, records, files and objects) optimized to deal with very large amounts of data stored on a permanent data storage device (which implies relatively slow access compared to volatile main memory). 3. A database query language and report writer to allow users to interactively interrogate the database, analyze its data and update it according to the users privileges on data. • It also controls the security of the database. • Data security prevents unauthorized users from viewing or updating the database. Using passwords, users are allowed access to the entire database or subsets of it called subschema. For example, an employee database can contain all the data about an individual employee, but one group of users may be authorized to view only payroll data, while others are allowed access to only work history and medical data. • If the DBMS provides a way to interactively enter and update the database, as well as interrogate it, this capability allows for managing personal databases. However, it may not leave an audit trail of actions or provide the kinds of controls necessary in a multi-user organization. These controls are only available when a set of application programmes is customized for each data entry and updating function. 4. A transaction mechanism, that ideally would guarantee the ACID properties, in order to ensure data integrity, despite concurrent user accesses (concurrency control), and faults (fault tolerance). • It also maintains the integrity of the data in the database. • The DBMS can maintain the integrity of the database by not allowing more than one user to update the same record at the same time. The DBMS can help prevent duplicate records via unique index constraints; for example, no two customers with the same customer numbers (key fields) can be entered into the database. See ACID properties for more information (Redundancy avoidance).

The DBMS accepts requests for data from the application program and instructs the operating system to transfer the appropriate data.

When a DBMS is used, information systems can be changed much more easily as the organization's information requirements change. New categories of data can be added to the database without disruption to the existing system.

Organizations may use one kind of DBMS for daily transaction processing and then move the detail onto another computer that uses another DBMS better suited for random inquiries and analysis. Overall systems design decisions are performed by data administrators and systems analysts. Detailed database design is performed by database designers.

Database servers are specially designed computers that hold the actual databases and run only the DBMS and related software. Database servers are usually multiprocessor computers, with RAID disk arrays used for stable storage. Connected to one or more servers via a high-speed channel, hardware database accelerators are also used in large volume transaction processing environments.

DBMSs are found at the heart of most database applications. Sometimes DBMSs are built around a private multitasking kernel with built-in networking support although nowadays these functions are left to the operating system.

B.2.2.2 Components of a database system In relational databases and flat file databases, a table is a set of data elements (values) that is organized using a model of vertical columns (which are identified by their name) and horizontal rows.

A database index is a data structure that improves the speed of operations on a database table. Indices can be created (manually or automatically) using one or more columns of a database table, providing the basis for both rapid random lookups and efficient access of ordered records.

The disk space required to store the index is typically less than that required by the table (since indices usually contain only the key-fields according to which the table is to be arranged, and excludes all the other details in the table), yielding the possibility to store indices in memory that might be too small for the entire table.

The main purpose of indexing is to speed data retrieval. Thus indexes should be created for the most frequently retrieved fields and or combinations of fields.

Database tables/indexes are typically stored in memory or on hard disk in one of many forms, ordered/unordered Flat files, ISAM, Heaps, Hash buckets or B+ Trees.

A flat file database describes any of various means to encode a data model (most commonly a table) as a plain text file.

Unordered storage typically stores the records in the order they are inserted, while having good insertion efficiency, it may seem that it would have inefficient retrieval times, but this is usually never the case as most databases use indexes on the primary keys, resulting in efficient retrieval times.

Ordered or Linked list storage typically stores the records in order and may have to rearrange or increase the file size in the case a record is inserted, this is very inefficient. However is better for retrieval as the records are pre-sorted

ISAM stands for Indexed Sequential Access Method, a method for storing data for fast retrieval. ISAM forms the basic data store of almost all databases, both relational and otherwise. In an ISAM system, data is organized into records, which are composed of fixed length fields. Records are stored sequentially. A secondary set of hash tables known as indexes contain "pointers" into the tables, allowing individual records to be retrieved without having to search the entire data set.

Data dictionaries contain details of all the files in the database, the records in each file, and the details of the fields in each record. Data dictionaries enforce standard data element definitions whenever end users and application programs use a DBMS to access an organization’s databases.

Items typically found in a DBMS data dictionary include:

• detailed descriptions of tables and fields • indexing information • referential integrity constraints • database schema definitions • stored procedures and database triggers • access control information, such as usernames, roles, and privileges • storage allocation parameters • database usage statistics

B.2.2.3 Files based on fixed and variable length records A flat file is a computer file that is usually read or written sequentially and does not have indexes that can be individuated from the individual records. It consists of one or more records. Each record contains one or more field instances. Each field instance can contain a data value, or be omitted.

Flat files may have variable length records or fixed length records. In flat files that have variable length records the file must be read sequentially, however, with fixed length records a flat file may be accessed randomly, although the lack of indexes makes this approach less desirable than, for instance, using a database table for quickly finding a specific record. Flat files date back to the earliest days of computer processing. Originally flat files were stored on punch cards, paper tape, or magnetic tape. These are inherently sequential. Flat files are still widely used, even for files stored on a disk. One reason is that sequential access is faster than indexed access, (also known as random access or direct access). Often each field has a fixed width. In the common case when all the fields and all the records are fixed width the flat file can be called a fixed width file. In a fixed width file there typically is no field delimiter and no record delimiter and field instances are never omitted. An empty field is indicated using a special filler value, e.g. spaces or zeroes. Fixed width records often contain 80 bytes, the width of a punch card. In a variable width record the fields are separated using a special character such as the tab character, the comma, or the pipe character. There can be records of many different types in the same flat file. A typical approach is for a file to have zero or more header records, one or more detail records, zero or more summary records, and zero or more trailer records. Flat files are still widely used for data transmission because they are compact and support high performance operations. Transmitting the same data using a relational approach would require many tables, one for each different record type. Another difference between flat files and relational tables is that in a flat file the order of the records can matter. Yet another difference is that in a flat file a field can occur more than once in a record.

B.2.2.4 Examples of business areas where DBMS are used

Examples of the databases: • Database of geographical data in GIS-system, • Database of medical histories in the hospital, • Database of books in library, • Database of marriage and divorce registrations in marital status department, • Database of bank transfers in bank, • Database of passengers in airport, • Database of registered vehicles

B.2.2.5 The components of a DBMS

A database engine is the underlying software component that a Database Management System (DBMS) uses to create, retrieve, update and delete (CRUD) data from a database. One may command the database engine via the DBMS's own user interface, and sometimes through a network port.

A database server is a computer program that provides database services to other computer programs or computers, as defined by the client-server model. The term may also refer to a computer dedicated to running such a program. Database management systems frequently provide database server functionality, and some DBMS's (e.g., MySQL) rely exclusively on the client-server model for database access.

In a master-slave model, database master servers are central and primary locations of data while database slave servers are synchronized backups of the master acting as proxies.

Database administration is the function of managing and maintaining DBMS software.

Often, the DBMS software comes with certain tools to help DBAs manage the DBMS. Such tools are called native tools. For example, Microsoft SQL Server comes with SQL Server Enterprise Manager and Oracle has tools such as SQL*Plus and Oracle Enterprise Manager/Grid Control. In addition, 3rd parties such as BMC, Quest Software, Embarcadero and SQL Maestro Group offer GUI tools to monitor the DBMS and help DBAs carry out certain functions inside the database more easily.

Another kind of database software exists to manage the provisioning of new databases and the management of existing databases and their related resources. The process of creating a new database can consist of hundreds or thousands of unique steps from satisfying prerequisites to configuring backups where each step must be successful before the next can start. A human cannot be expected to complete this procedure in the same exact way time after time - exactly the goal when multiple databases exist. As the number of DBAs grows, without automation the number of unique configurations frequently grows to be costly/difficult to support. All of these complicated procedures can be modeled by the best DBAs into database automation software and executed by the standard DBAs. Software has been created specifically to improve the reliability and repeatability of these procedures such as Stratavia's Data Palette and GridApp Systems Clarity. Open Database Connectivity (ODBC) provides a standard software API method for using database management systems (DBMS). The designers of ODBC aimed to make it independent of programming languages, database systems, and operating systems.

The ODBC specification offers a procedural API for using SQL queries to access data. An implementation of ODBC will contain one or more applications, a core ODBC "Driver Manager" library, and one or more "database drivers". The Driver Manager, independent of the applications and DBMS, acts as an "interpreter" between the applications and the database drivers, whereas the database drivers contain the DBMS-specific details. Thus a programmer can write applications that use standard types and features without concern for the specifics of each DBMS that the applications may encounter. Likewise, database driver implementers need only know how to attach to the core library. This makes ODBC modular.

B.2.2.6 Database administrator (DBA)

A database administrator (DBA) is a person who is responsible for the environmental aspects of a database. In general, these include:

Installation of new software — It is primarily the job of the DBA to install new versions of DBMS software, application software, and other software related to DBMS administration. It is important that the DBA or other IS staff members test this new software before it is moved into a production environment. Configuration of hardware and software with the system administrator — In many cases the system software can only be accessed by the system administrator. In this case, the DBA must work closely with the system administrator to perform software installations, and to configure hardware and software so that it functions optimally with the DBMS. Security administration — One of the main duties of the DBA is to monitor and administer DBMS security. This involves adding and removing users, administering quotas, auditing, and checking for security problems. Data analysis — The DBA will frequently be called on to analyze the data stored in the database and to make recommendations relating to performance and efficiency of that data storage. This might relate to the more effective use of indexes, enabling "Parallel Query" execution, or other DBMS specific features. Database design (preliminary) — The DBA is often involved at the preliminary database-design stages. Through the involvement of the DBA, many problems that might occur can be eliminated. The DBA knows the DBMS and system, can point out potential problems, and can help the development team with special performance considerations. Data modelling and optimization — By modelling the data, it is possible to optimize the system layout to take the most advantage of the I/O subsystem. Responsible for the administration of existing enterprise databases and the analysis, design, and creation of new databases. Proactively monitor systems for optimum performance and capacity constraints Establish standards and best practices for SQL Interact with and coach developers in Structured markup language scripting


B.2.3 Data modelling

B.2.3.1 Physical and logical view

Data abstraction is the enforcement of a clear separation between the abstract properties of a data type and the concrete details of its implementation. The abstract properties are those that are visible to client code that makes use of the data type--the interface to the data type--while the concrete implementation is kept entirely private, and indeed can change, for example to incorporate efficiency improvements over time. The idea is that such changes are not supposed to have any impact on client code, since they involve no difference in the abstract behaviour. A database management system provides the ability for many different users to share data and process resources. But as there can be many different users, there are many different database needs. The question now is: How can a single, unified database meet the differing requirement of so many users? A DBMS minimizes these problems by providing two views of the database data: a physical view and a logical view. The physical view deals with the actual, physical arrangement and location of data in the direct access storage devices (DASDs). Database specialists use the physical view to make efficient use of storage and processing resources. Users, however, may wish to see data differently from how they are stored, and they do not want to know all the technical details of physical storage. After all, a business user is primarily interested in using the information, not in how it is stored. The logical view/user’s view, of a database program represents data in a format that is meaningful to a user and to the software programs that process those data. That is, the logical view tells the user, in user terms, what is in the database. One strength of a DBMS is that while there is only one physical view of the data, there can be an endless number of different logical views. This feature allows users to see database information in a more business-related way rather than from a technical, processing viewpoint. Thus the logical view refers to the way user views data, and the physical view to the way the data are physically stored and processed.

B.2.3.2 Differences between logical and physical data models In the table below the main differences between logical and physical data models are presented

Logical Data Model Physical Data Model Includes entities, attributes and relationships Includes tables, columns, keys, data types, validation rules, database triggers, stored procedures, domains, and access constraints Uses business names for attributes Uses abbreviated column names limited by the database management system (DBMS) Is independent of technology (platform, DBMS) Includes primary keys and indices for fast data access. Is normalized to 4th normal form May be de-normalized to meet performance requirements Does not include any redundant or derived data May include redundant columns or results of complex or difficult to recreate calculation columns Business Subject Matter Experts (SMEs) validate and approve the model Physical Modeller lead the modelling activity


Logical modelling benefits

• Clarifies functional specifications and avoids assumption, • Confirms business requirements, • Facilitates business process improvement, • Focus on requirements independent of technology, • Decreases system development time and cost, • Becomes a template for the enterprise, • Facilitates data re-use and sharing, • Gathers metadata, • Foster seamless communication between applications, • Focuses communication for data analysis and project team members, • Establishes a consistent naming scheme. Read more about data models and data modelling (http://en.wikipedia.org/wiki/Data_modeling)

B.2.3.3 Principles of record-based logical models

In a hierarchical data model, data is organized into a tree-like structure. The structure allows repeating information using parent/child relationships: each parent can have many children but each child only has one parent. All attributes of a specific record are listed under an entity type. In a database, 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. The most recognized example of hierarchical model database is an IMS designed by IBM.

An example of a hierarchical data model would be if 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 departments the employee works. The Department table represents a parent segment and the Employees table represents a Child segment. These two segments form a hierarchy where a department may have many employees, but each employee may belong only to one department.


Hierarchical data model

The network model is a database model conceived as a flexible way of representing objects and their relationships. Its original inventor was Charles Bachman, and it was developed into a standard specification published in 1969 by the CODASYL Consortium. Where the hierarchical model structures data as a tree of records, with each record having one parent record and many children, the network model allows each record to have multiple parent and child records, forming a lattice structure.

Network model The chief argument in favour of the network model, in comparison to the hierarchic model, was that it allowed a more natural modeling of relationships between entities. Although the model was widely implemented and used, it failed to become dominant for two main reasons. Firstly, IBM chose to stick to the hierarchical model with semi-network extensions in their established products such as IMS and DL/I. Secondly, it was eventually displaced by the relational model, which offered a higher-level, more declarative interface. Until the early 1980s the performance benefits of the low-level navigational interfaces offered by hierarchical and network databases were persuasive for many large-scale applications, but as hardware became faster, the extra productivity and flexibility of the relational model led to the gradual obsolescence of the network model in corporate enterprise usage.

B.2.3.4 Principles of object-based logical models

An entity-relationship model (ERM) is an abstract conceptual representation of structured data. Entity-relationship modelling is a relational schema database modelling method, used in software engineering to produce a type of conceptual data model (or semantic data model) of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created using this process are called entity-relationship diagrams, or ER diagrams or ERDs for short. Originally proposed in 1976 by Peter Chen, many variants of the process have subsequently been devised.

The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modelling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain universe of discourse (i.e. area of interest). In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design". An entity may be defined as a thing which is recognised as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity we normally speak of some aspect of the real world, which can be distinguished from other aspects of the real world (Beynon-Davies, 2004). An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used, following Chen we should really distinguish between an entity and an entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term. Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. Entities are represented as rectangles. A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship. Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; the proved relationship may have a date attribute. Attributes are represented as ellipses connected to their owning entity sets by a line. Every entity (unless it is a weak entity - an entity that cannot be uniquely identified by its attributes alone) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key. Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set. Lines are drawn between entity sets and the relationship sets they are involved in. If all entities in an entity set must participate in the relationship set, a thick or double line is drawn. This is called a participation constraint. If each entity of the entity set can participate in at most one relationship in the relationship set, an arrow is drawn from the entity set to the relationship set. This is called a key constraint. To indicate that each entity in the entity set is involved in exactly one relationship, a thick arrow is drawn. Associative entity is used to solve the problem of two entities with a many-to-many relationship

B.2.4 The Relational Model

B.2.4.1 The benefits of a relational database

Relational database theory uses a different set of mathematical-based terms, which are equivalent, or roughly equivalent, to SQL database terminology. The table below summarizes some of the most important relational database terms and their SQL database equivalents.

Relational term SQL equivalent relation table tuple row attribute column

A relational database is a collection of relations (frequently called tables). Other items are frequently considered part of the database, as they help to organize and structure the data, in addition to forcing the database to conform to a set of requirements.

In relational databases and flat file databases, a table is a set of data elements (values) that is organized using a model of vertical columns (which are identified by their name) and horizontal rows. A table has a specified number of columns, but can have any number of rows. Each row is identified by the values appearing in a particular column subset, which has been identified as a candidate key.

A relation is defined as a set of tuples that have the same attributes. A tuple usually represents an object and information about that object. Objects are typically physical objects or concepts. A relation is usually described as a table, which is organized into rows and columns. All the data referenced by an attribute are in the same domain and conform to the same constraints.

The relational model specifies that the tuples of a relation have no specific order and that the tuples, in turn, impose no order on the attributes. Applications access data by specifying queries, which use operations such as select to identify tuples, project to identify attributes, and join to combine relations. Relations can be modified using the insert, delete, and update operators. New tuples can supply explicit values or be derived from a query. Similarly, queries identify tuples for updating or deleting.

A domain describes the set of possible values for a given attribute. Because a domain constrains the attribute's values and name, it can be considered constraints. Mathematically, attaching a domain to an attribute means, “all values for this attribute must be an element of the specified set”. The character data value 'ABC', for instance, is not in the integer domain. The integer value 123 satisfies the domain constraint.

The benefits of well-designed relational database are the following: • Non-redundancy. This means that data existing in database cannot be derived by combining the other data of the same database. Examples of redundancy are columns and rows with duplicated data. There are multiple techniques and steps for getting rid of redundancy. Mentioned techniques and steps will be scrutinized in the paragraph of “normal forms”. It is obvious that needed or requested duplications can exist, but such duplications are related to database back-up or storing in RAID system. Such duplication is related to physical level and has no connection to logical level

• Referential integrity in a relational database is consistency between coupled tables. Referential integrity is usually enforced by the combination of a primary key or candidate key (alternate key) and a foreign key. For referential integrity to hold, any field in a table that is declared a foreign key can contain only values from a parent table's primary key or a candidate key. For instance, deleting a record that contains a value referred to by a foreign key in another table would break referential integrity. The relational database management system (RDBMS) enforces referential integrity, normally either by deleting the foreign key rows as well to maintain integrity, or by returning an error and not performing the delete. Which method is used would be determined by the referential integrity constraint, as defined in the data dictionary.

• Database scalability. A number of different approaches enable databases to grow to very large size while supporting an ever-increasing rate of transactions per second. Not to be discounted, of course, is the rapid pace of hardware advances in both the speed and capacity of mass storage devices, as well as similar advances in CPU and networking speed. Beyond that, a variety of architectures are employed in the implementation of very large-scale databases. One technique supported by most of the major DBMS products is the partitioning of large tables, based on ranges of values in a key field. In this manner, the database can be scaled out across a cluster of separate database servers. Also, with the advent of 64-bit microprocessors, multi-core CPUs, and large SMP multiprocessors, DBMS vendors have been at the forefront of supporting multi-threaded implementations that substantially scale up transaction processing capacity.

B.2.4.2 Normalization of the database

In order to avoid data redundancy there is a possibility to use the process that tries to modify the structure of database by forcing the table to pass through three sequential normal forms. First normal form (1NF): it is said, that table is in first normal form, if it describes only one entity and it does not include vectors and duplicated attributes. Let us observe the table, which includes the data of lectures for one course, for example. Each row of lecture has a code, lecturer and student data. This table is not in first normal form, because student data is a vector that corresponds to lecture. Subject code Subject Lecturer Students’ code Students’ family name Students’ name I1 Design Lind T1 Rooväli Marek I1 Design Lind T2 Peterson Maria I1 Design Lind T3 Martson Ella I2 Creation Sepp T2 Peterson Maria I2 Creation Sepp T3 Martson Ella

More precisely, each lecture is related to more than one student and this is expressed with saying that there is a student vector (group of students) in each lecture. To transform this table into first normal form, it is necessary to separate student data and lectures and create new table for students. “Lecture” table has as the same amount of rows as there are different lectures. Table of “students” who are in list of lectures has as many rows as there are students registered to the respective lecture and each student should be listed there more than once. This table should also have an additional column with the code of lecture where the student has registered her/himself.

Subject Lecturer Design Lind Fashioning Sepp Subject code Students’ code Students’ family name Students’ name I1 T1 Rooväli Marek I1 T2 Peterson Maria I1 T3 Martson Ella I2 T2 Peterson Maria I2 T3 Martson Ella Table “Registered students” Second normal form (2 NF): table is in second normal form if it is in first normal form and all the attributes depend only on primary key. Looking at the previous table “registered students”, the primary key, needed to differentiate the rows from each other, should consist of lecture code and student code. We can notice that student name and family name depend only on student code and not the whole primary key. To transform the table into second normal form we have to sort out the data, which is not completely dependant on primary key and add such data to new table “students”. It is worth to notice that there will be no information loss, because the column “student code” exists in both tables and enables mutual relations of those tables.

Subject code Students’ code I1 T1 I1 T2 I1 T3 I2 T2 I2 T3 Table “Registered students”

Students’ code Students’ faily name Students’ name T1 Rooväli Marek T2 Peterson Maria T3 Martson Ella Table “Students”

Third normal form (3 NF): table is in third normal form if it is in second normal form and all its’ attributes not related to primary key are independent from each other. As example, consider the students table, which includes personal data as the following table.

Code Family name Name Date of birth Age Last update S01 Rooväli Marek 11.09.1955 50 12.11.2001 S02 Peterson Maria 01.02.1990 14 15.12.2004 S03 Martson Ella 09.06.1978 26 26.01.2005 Table “Students”

Age in this table can be calculated through the birth date and therefore this information is redundant. This fault can be fixed easily by transforming the student’s table into third normal form. Sometimes it is not easy to identify the dependency. Let us take a look at the “lectures” table, which registers the number of total seats for each lecture. Number of available seats can be calculated by disuniting the number of total seats from number of registered students. Column “available seats” should be removed from the table in order to transform the table into third normal form. Subject code Subject Lecturer Total seats Available seats I1 Design Lind 5 2 I2 Creation Sepp 6 4 Table “Lectures”

B.2.5 Query Languages

B.2.5.1 Procedural and non-procedural query languages

SQL is designed for a specific purpose: to query data contained in a relational database. SQL is a set-based, declarative, non-procedural query language - single command directly brings desired results. As the opposite, for obtaining the same result in an imperative (procedural) language such as C or BASIC, one has to write a sequence of commands (to compose the “procedure”). However, there are extensions to Standard SQL, which add procedural programming language functionality, such as control-of-flow constructs. Some example of procedural extensions of SQL are Oracle’s PL/SQL and Sybase’s T SQL.

B.2.5.2 Fundamental operations of the relational algebra

In order to understand its efficiency in data searches, it is useful to start from definitions of relational algebra and explore its operation. • Union of two tables. This is a set of rows, which derive at least from one union. This can be understood as table, which is compounded from similar columns of two tables. • Difference of two tables. This is a set of rows, which exists in one table and misses from the other (supposing that those two table have same columns). • Direct product. This is a set of rows, which is achieved by collating the rows of two tables with each other one by one. Example of direct product of two tables:

Student code 	 Name

S1 Marek S2 Maria S3 Ella


Lecture 	 Student

History S1 Histpry S3 Geography S1 Geography S2

Student code	 Name 	 Lecture 	 Student

S1 Marek History S1 S1 Marek History S3 S1 Marek Geography S1 S1 Marek Geography S2 S2 Maria History S1 S2 Maria History S3 S2 Maria Geography S1 S2 Maria Geography S2 S3 Ella History S1 S3 Ella History S3 S3 Ella Geography S1 S3 Ella Geography S2 Cartesian product of “Users” and “Courses”

• Selection from table. This is a set of rows, which corresponds to query constraints (or series of query constraints). Rows that correspond to query constraints “Student code” are marked in grey (in previous table). “Student code” corresponds to “Lectures” in “Student” table. Those rows are copied to the following table.

Student code	 Name 	 Lecture	 Student

S1 Marek History S1 S1 Marek Geography S1 S2 Maria Geography S2 S3 Ella History S3 Selection from direct products

• Projection. Projection represents the subset of columns, which is achieved from direct product by removing undefined attributes – in other words, columns that are duplicated or consist of non requested information are removed. In previous example the column named “Students” is removed as the result of projection operation, because it consists of the same information as the column called “Student code”.


Student code	 Name	 Lecture

S1 Marek History S1 Marek Geography S2 Maria Geography S3 Ella History Projection

Conjunction. Summing operation is basicly direct product together with following selection. If selection consists of equal constraints only, then the operation is called equivalent relation. Result of equivalent relation is a special summing of two different tables. If projection follows to the equivalent relation, then the name of the operation is natural join. Two achieved tables (described in last example) are the examples of equivalent relation and natural join. • Renaming. This is used for renaming the columns of the table. For example, a column called “Student code " can be renamed as "Code".

Code Name Lecture S1 Marek History S1 Marek Geography S2 Maria Geography S3 Ella History Renaming

B.2.5.3 Components of SQL language

Moving from relatsional algebra to SQL it is important to notice that this language includes multiple internal parts (components). Very important components are: • Data Definition Language (DDL), which is a part of SQL, used for defining data. Language includes commands: create, drop and alter. Those commands enable to create tables, views and indexes, also removing them and altering. Those commands are described in next paragraph. • Data Manipulation Language (DML) is a part of SQL, which is used for data manipulation. This language includes such commands as: insert, delete, and update. Those commands enable to insert, delete or update rows. In addition to those commands there is also a command called “select”, which enables to require data. • Supportive commands are related to security and user rights (grant, revoke) data operations (commit, rollback, rollforfard) or programming language (operations on command line).

B.2.5.4 SQL DDL commands

Command “create table” enables to create table and its simplified format is: create table name (colname coltype [not null], ...); Following keywords are used: tname – name of table colname – name of column coltype – data type of the column not null – if added, then this row can not consist an empty value and data has to be inserted to this column. Some possible data types are given in following table:

Type Definition

Integer	 32 byte integer
Smallint	 16 byte integer
Float	 64 byte number with floating point (12 significant digits)
Smfloat	 32 byte number with floating point (7 significant digits)
char(n)	 String (text) n from symbol 
varchar(n)	 Variable length string (highest number of symbols is n)
Date	Date  (number of dates after 31 Dec. 1899) ( 01 Jan 1900 is date 1) (known also as the date of  Juliuse calendar)

Name of table and list of table columns have to be added to the command for creating the table. Data type has to be shown for each column. It has to be pointed out if the column can or cannot have null value. Null value means an empty field, not zero value (in case of SQL language)!

Examples: Create table students (tcode integer not null, name char(10) not null,family name char(15) not null, birth date); For deleting the whole table (together with its structure and content) the following command can be used: drop table tname;

where tname indicates the name of table to be deleted. Examples: Drop table students; For changing the structure of the table the following commands can be used: alter table tname modify ( colname coltype [not null], ...); alter table tname add ( colname coltype [not null], ...); alter table tname delete ( colname, ...); The meaning of tname, colname, not null is mentioned above (at creating the table). First command alters the data types of the column/columns. If table is empty, then it is always possible to alter the data types. Altering the data types might be impossible if data already exists in table. Possibility (or impossibility) to alter the data in case of already completed table depends on the fact is the data changeable or not. For example, it is always possible to alter the number into a string. Opposite is possible only if the string represents the number. Some transactions might cause the loss of data: for example altering a string into a shorter (length) string; or altering float type of data into smfloat type of data. Second row of commands enables to insert column/columns to the table: this might be impossible if table includes data and column that needs to be inserted does not allow null value (some SQL versions enable to use “default value” for solving mentioned problem). Third row of commands enables to delete the column: if the column includes the data then data will be deleted too.

Examples: Alter table students add (length smallint); Alter table students modify (length float); Alter table students delete (length); Following command is used for creating the index: create [unique] index idxname on tname (colname, ...); where following keywords are used: unique – index has to be unique, if such command is used; dxname – name of index; tname – name of table; colname – name of column. It is useful to know that it is impossible to create unique index for the table that already includes data, which does not conform to the nature of unique index.

Exapmles: Create unique index students is students (tcode); Create index student name is students (family name, name); Following command is for deleting the index: drop index idxname; where idxname is the name of indext that needs to be deleted. It does not matter if the index is unique or not in case of deleting the index. Language does not include the possibility to alter indexes: for altering the index, it first needs to be deleted and then new one has to be created. Deleting the index does not cause loss of data, but it is useful to know that deleting the unique index might cause the situation, where data insertion in between can cause the impossibility to recreate it.

Examples: drop indexstudent name;


B.2.6 SQL queries

B.2.6.1 Basic SQL DML commands

While moving to data manipulation language, we can mark that data can be inserted to the table with following command: insert into tname [(colname, ...)] values (colval, ...); where following keywords are used: tname – name of table, where the data is inserted; colname – name of column, where the data is inserted; colval – concrete data, which is inserted. Data insertion operation can fail for several reasons: data that needs to be inserted duplicates index values or does not conform to columns’ data type.

Examples: Insert into students (tcode, name,family name) values (12, “Juhan”, “Juurikas”); Deleting operation of rows enables to add deletion conditions, representing a new syntax element clause “where”. delete from tname [where colname condition {colval|colname} [oprel ...]]; where following keywords are used: Tname – name of table, from which the data needs to be deleted; colname – name of column; condition – conditional operator; colval – value that is compared with the content of colname; oprel – relational operator. Conditions expaned upon are rather simple. Any possible conditions of clause “where” are much wider and are left out from present discussion.

Conditions Definitions

=	 Condition is correct, if operators’ both sides are equal.
!=	 Condition is correct, if operators’ both sides are different.
> >= <= <	 Condition is correct, if operators’ both sides correspond to the conditions of shown calculation.
like	 Condition is correct, if the left side of the term “like”includes right sided conditions (symbols). Meta marks as “%” symbol can be used.. Symbol % is used as whichever order of symbols.
matches	 Condition is correct, left side corresponds to rightsided conditions (symbols) Meta marks can be used. 



Relational operator Definitions

And	 Expression is correct, if conditions both preceding and following to the operator are correct.
Or	 Expression is correct, if at least one of the two conditions is correct. 
Not	 Denies the condition following to the operator (corresponds to opposite value).

Following example demonstrates how to delete all the student entries with family name Juurikas and who is born before 1st of January 1983. For deleting the row, it has to fulfill both conditions and this for the operator is used . Examples: delete from students where birthdate <”01.01.1983” and family name=“Juurikas”; Altering the values of the table can be done with the following command: update tname set colname=valcol, ... [where colname condition {colval|colname} [oprel ...]]; where the following keywords are used: tname – name of table, from which the data needs to be deleted; colname – name of column; valcol – value given to column; condition – conditional operator; colval – value that is compared with the content of colname column; oprel – relational operator.

B.2.6.2 SQL clauses

Data refreshing command enables to refresh multiple rows and columns of the table at the same time. Row selection is done with “where” clause, but it needs to be shown in column refresh command. In following example, the name and family name of all the students, whose code is 2, is refreshed; if unique index is defined as code (see the example next to index definition), then only one entry is refreshed (or non, if there is no student with code 2).

Examples: update students set family name=“Juurikas” and name=”Piret” where tcode=2;

Until now we have looked at the commands for altering the data. Now we will explore how to get needed information from the table. Very flexible command called “select” is used for that. select ( colname, ...) from tname [where ...] [group by (colname, ...)] [order by (colname, ...)] [having ...] [into [temp] table tname]; Here the following keywords are used: colname – name of column; tname – name of table, where from the data needs to be selected; where – clause, which was described above next to “delete” and “update” commands; having – a little similar to clause where, but partial results are considered. Clause “order by” enables to give out the data in sorted queue. Clause “group by” enables data grouping. In case of commands, where all the mentioned clauses are used, the commands are applied in following order: first “where”, then “order by” and “group by” and then “clause “having”. Knowing the complexity and flexibility of clause “select”, we take a look at multiple different examples.

In first example we show how to select all the information from the table: “*” mark instead of the list of columns shows that all the columns of the table have to be selected. All the rows can be selected due to the fact that clause “where” is missing.

Examples: Select * from students; In second example, all the names and family names of the students, who were older than 18 years on December 31st 2003, are selected. Result is ordered by the family name and name. Please notice that columns’ ordering order must be shown after “order by”.

Examples: select family name, name from students where birthdate <=”31.12.1985” order by family name,name;

In third example, all students with the same name are grouped; name together with the number of the students with same name are selected. Counting function “count(*) gives out the number of grouped rows. Example does not have the “where” clause, even if it could have. Examples: select name, count(*) from students group by name order by name;

Forth example shows how to use clause “having” for selecting rarely occurring names or names that occur only once. Examples: select name, count(*) from students group by name order by name having count(‘)=1;

In fifth example, the family names and names of the students participating in lecture are selected. This is done through creating relations between the tables of students and lectures. For understanding the command, it should be known, that table of lectures includes columns of lecture and student (student participates in lecture). You could notice two columns with names “name” while exploring the command – those columns are differentiable, because the name of the table is before the name of the column and they are related with intervening point. Such syntax is also used for showing the conditions in “where” clause, but this is used in interest of perspicuity (where student = code can be used without problems). For understanding how the command works, we take a look how DBMS performs it: • direct product between the tables of lectures and students is found; • only the rows, where the value of “student” column is equal to the value of “code” column, are selected. • projection, which deletes all the unsuitable columns, is created. • query from the table based on selected columns (lectures.student, students.name, family name), is done. All those operations conform to natural join.

Examples: select lectures.name, family name, students.name from lectures, order by lectures.name, family name, students.name where lectures.student=students.code;

6th and last example uses 5th example and performs complement, which also enables to select lectures, where no students have registered themselves. In such case the rows include the data of lecture and such rows, where student data is missing (no sudents registered to the lecture). From commands’ position it is sufficient, if word “outer” is added before the name of the student table. Such type of relation is outer join or left join. Syntax of outer join can be much more complex and dependent on used SQL language standard.

Example: select lectures.name, family name, students.name from lectures, outer students order by lectures.name, family name, students.name where lectures.student=students.code;

As we have explored the command “select” sufficiently now, we can move on and explore user command “create view”. User view is like the table itself from the point of functionality, but it is created with the command “select”. Mainly, it is the possibility to bring forth the tables by using different possibilities. Syntax of the command: create view vname as select ... ;

Used keywords: vname – name of generated view; select – selective command, which shows how the data is sent. For example, lets take a look at the view, which gives present data about the students in list of lectures (list of registered students).

Examples: create view registered as select lectures.name, family name, students.name from lectures, students where lectures.student=students.code;

Opposite to the command for generating the view is the command for deleting the view, as it could be done with tables and indexes. Its syntax is: drop view vname; where “vname” is the name of the view to be deleted.

Examples: drop view registered;

B.2.6.3 Special SQL commands

For the conclusion of those brief descriptions, some of the managing commands of the data transactions are shown: commit work; rollback work; Commands for altering the data (insert, delete, update) do not alter the content of the table, they register the needed changes instead (usually in logs). Those changes are performed only in case of command “commit”. If the command “rollback” is performed, then changes will be rolled back. Storing logs on magnet tape enables data restoring: first the data is restored with command “restore”, thereafter all the changes on tape are applied (operation is called rollforward). Such restoring process assures that none of the transactions is getting lost until deleted with the command “rollback” or left unfinished (transactions, to which either “commit” nor “rollback” is performed before the deadlock or any other fault of the database server).

B.2.7 Database Administration and Security

B.2.7.1 Functions of a DBA

Database management operations are performed by one or more database administrators, who are responsible for: • Database configuration management; • Schema management with management programs existing in DBMS. DDL commands should be used; • Configuration of user access policy.

The fact that DBA is not the owner of the database does not mean anything (condominiums’ administrator is also not the owner of the dwellings). Administrator is a highly qualified technician, who acts according to the usual action plan approved by the director (owner) of the organization producing or using the data. Until now we have not talked about the role of DBA from the point of view of the DBs’ physical view. First of all, DBAs’ role is usually not the standard management, because it is DBMS sellers’ responsibility to manage the physical view. Operations can be different for DBMS-s, but they mirror basic needs. Those operations are mostly related to DBMS’s security and efficiency (either performing – or functioning speed). Security needs are related to data confidentiality and availability. There are appropriate SQL commands for managing confidentiality, we will talk about it later. Availability needs are usually solved on physical level through redundancy or data duplications and also back up policies. Redundancy can be either local (use of RAID discs) or managed from distance (in different server due to the database mirroring policy).

Efficiency improving needs is solved on physical level through the configuration of the physical view: • New storing devices (raw devices or hard discs) used for working environment instead of using file system (storing through the FMS). This is the selection that creates complexities and is therefore also expensive, but it can highly improve DBMS’s efficiency, which has to manage huge amount of data; • Dividing DB between multiple servers in order to achieve higher calculation efficiency; • Using multi-threaded DBMS, which can use more processors or divide commands (queries) effectively in each case; • Modifying the divided memory space the way that it is capable to adapt the amount of processes accompanied by the required widening. • Precisely defining the logs and transaction management policy (this is a question of physical and logical view’s frontier. Confidenciality can also be managed with appropriate SQL commands. Grant and revoke command permit different authorisations for accessing data. Example on that is the syntax of the two commands regulating the DB accessing rights. grant role to user [identified by pwd] [with grant option]; revoke role from user; Used keywords: role – can be database administrator, resource, connection; user – username, to which the rights are granted or attainted; pwd – password; grant option – enables the user who has received the rights to grant the rights identical to received ones, to the other user.

The role of database administrator is clearer that the role of the other database users; even if they have comparatively less activity rights comparing to database administrator. Database administrator can do everything though the user with resourde right can not modify the schema and those who have the right to connect, can not alter data. It is important to understand that keywords describing different roles can be different in different DBMS; therefore it is necessary to read carefully user manual before granting the rights or writing the null-command.

B.2.7.2 Database administration procedures

DBMS is an IT product, which is used for data managing in organization. DBMS consist basicly the following administration procedures: • Management programs for managing physical views. For example changing the configuration (so, that it can be adjusted according to user requirements), modifying program efficiency (functional speed i.e. performance) or determining back-up management policy. • Schema management program, which is used for managing logical view with DDL commands (described more precisely in clause 2.7); • Data management programs, which enable to operate with managing devices and ad hoc changes of data that is kept in DB, using DML commands) and without using any other program. Simple command interpretation console is usually used for managing commands. Managing commands were also handled in previous clause.

B.2.7.3 Security and integrity problems

Database security is the system, processes, and procedures that protect a database from unintended activity. Unintended activity can be categorized as authenticated misuse, malicious attacks or inadvertent mistakes made by authorized individuals or processes. Database security is more critical as networks have become more open.

Databases provide many layers and types of information security, typically specified in the data dictionary, including:

• Access control • Auditing • Authentication • Encryption • Integrity controls

Database security can begin with the process of creation and publishing of appropriate security standards for the database environment. The standards may include specific controls for the various relevant database platforms; a set of best practices that cross over the platforms; and linkages of the standards to higher level polices and governmental regulations.

An important procedure when evaluating database security is performing vulnerability assessments against the database. A vulnerability assessment attempts to find vulnerability holes that could be used to break into the database. Database administrators or information security administrators run vulnerability scans on databases to discover misconfiguration of controls within the layers mentioned above along with known vulnerabilities within the database software. The results of the scans should be used to harden the database in order to mitigate the threat of compromise by intruders.

A program of continual monitoring for compliance with database security standards is another important task for mission critical database environments. Two crucial aspects of database security compliance include patch management and the review and management of permissions (especially public) granted to objects within the database. Database objects may include table or other objects listed in the Table link. The permissions granted for SQL language commands on objects are considered in this process. One should note that compliance monitoring is similar to vulnerability assessment with the key difference that the results of vulnerability assessments generally drive the security standards that lead to the continuous monitoring program. Essentially, vulnerability assessment is a preliminary procedure to determine risk where a compliance program is the process of on-going risk assessment.

The compliance program should take into consideration any dependencies at the application software level as changes at the database level may have effects on the application software or the application server. In direct relation to this topic is that of application security.

Application level authentication and authorization mechanisms should be considered as an effective means of providing abstraction from the database layer. The primary benefit of abstraction is that of a single sign-on capability across multiple databases and database platforms. A Single sign-on system should store the database user's credentials (login id and password), and authenticate to the database on behalf of the user.

Another security layer of a more sophisticated nature includes the real-time monitoring of database protocol traffic (SQL) over the network. Analysis can be performed on the traffic for known exploits or network traffic baselines can be captured overtime to build a normal pattern used for detection of anomalous activity that could be indicative of intrusion. These systems can provide a comprehensive Database audit trail in addition to the intrusion detection (and potentially protection) mechanisms.

When a network level audit system is not feasible a native database audit program should be instituted. The native audit trails should be extracted on a regular basis and transferred to a designated security system where the database administrators do not have access. This ensures a certain level of segregation of duties that may provide evidence the native audit trails were not modified by authenticated administrators. Generally, the native audit trails of databases do not provide sufficient controls to enforce separation of duties; therefore, the network and/or kernel module level host based monitoring capabilities provides a higher degree of confidence for forsenices and preservation of evidence.

We can formulate following requirements by dividing possible solution according to considered security aspects: • About confidentiality: first counter method is correct granting of rights by restricting the rights of access and amount of possible operations (activities) for each single table. One counter method that does not claim additional expenses is obviously correct management of equipment and back up copies. This has to be done the way that everything that is not accessible through the DBMS is also not accessible physically. Those counter methods are effective, because confidenciality risk derives mostly from cases of unauthorized access. • About integrity: risk of consequential loss of integrity and coherency is mainly related to program functioning faults (and faults caused bu such functioning faults). Presumptive reason is anomalies during data insertion. There are multiple methods of reacting: o First: access to data should be controlled and restricted the way, that only authorized users can change the data. o Second: DB schema should be influenced by restrictions (unique indexes, referential integrity). o Third: main attention should be focused on transaction management. • Availability requirements raise two different type of specific problems: o First it is necessary to determine the amount of hardware adequate for DBMS and appropriate configuration, that can manage complex and complicated load. o Second problem is related to availability maximizing policy, which is based on usage of RAID, redundant processors (like multiple prospectors) or remote-controlled backup solutions (mirroring). o Obviously there are no guaranties. This why the strategy of reducing the damages should be aim at. Back-up policy is necessary, not only for enabling fast data restoring, but also for avoiding possible loss of data. Reducing the periods between back-ups and permanent monitoring of transactions (online logging) can be recommended as precautions. Those precaution help to reduce the loss of transactions and amount of unfinished transactions during the DBMSs’ fault or deadlock.

B.2.7.4 Different security policies

We have talked about security in informatics also in previous chapters. If we talk about databases, then security has an important roll in it. Database security is represented by three aspects: confidentciality (only authorized persons’ access to information), integrity (undesirable changes in information is kept away) and availability (information is always accessible, when it is needed). Risks can derive from: • Human factors. For example negligence, access attempts of unauthorized persons or infringement of actual data. Dangers are often derived from the organizations itself (internally) and this is mainly the problem of confidenciality. Still, human factors can also influence integrity and in a less degree also the availability of software products. • Physical factors. For example hardware’s fault, which inevitably influences servers. Such risks influence availability and data integrity. • Factors related to operation system, because DBMS has to be based on services of operation system. Risk derives from functional faults, which can cause data corruption, but also from vulnerability, which could also classified under the human factors, enabling the intrusion, which would be impossible otherwise. • DBMS can have security problems itself (similarly to operation system). Such problems can influence all three mentioned security aspects.

B.2.7.5 Recovery schemes

Instead of discussing the reasons of different problems, we can divide counter-methods as follows: • Logical faults, which derive from incorrect data insertion or faults of procedures, can be avoided with correct DB constraints, such as defining primary key, controlling the referential integrity or using logical views for transactions. Obviously it’s not possible to avoid or remove all the faults. For example inserting 5 instead of 3 is not identifiable: but, if the fault is found or recognized, then fault repair process for refreshing the data should follow. • System faults or deadlocks can be avoided with redundancy (as it is usually done in aeronautical sector, where multiple system processes are functioning with the same data in parallel together with voting mechanism, which rejects the concurrent results). Knowing the general level of the system reliability, the operations are typically based on logics of reducing the damage together with the plan of performing back-up copies. In case the high level availability is required, it could be a good idea to work with detached copy of database. It should be done the way, that if the system fault accures, then it would be possible to redirect the load to the other database until the recovering operations are over. • RAID discs are usually used for reducing the risk of disc device faults: in such cases it is possible to continue the work even if one single disc refuses to function. It is also possible to use automatic disc replacing technique for replacing the disc in fault. In case if multiple discs are in fault at the same time, the back-up policy is used for recovering the data. Distant mirroring policy might also be a reasonable solution.

B.2.8 Data Warehousing and Data Mining

B.2.8.1 Data warehousing (DW)

Despite of the fact that the theory of relational database (RDB) specifies that only one single database has to store all the information of the organization, there are several reasons for owning multiple databases and this why many organizations own multiple databases and they all contain a lot of information. Precise relations between the data are defined already in phase of designing the single database (for example relations between the customer and invoice or invoice and payment etc). This field has still some constraints thanks to the existence of different databases: some of them have remained for supporting old applications (defined as legacy); others are simply for separating different activities (as for separating market analyses activities from company’s resource planning system); some are based on different technology (for example sorting systems based on news (which in turn are based on text searching products) can not always be integrated to relational database, which includes company data). If data can “cross” (there exists the possibility to define relations between them), then interesting hidden information can come out. Data warehousing and data mining got their names after integration process of data coming from multiple sources and the analyses phase following to it. Data warehouse capability does not derive only from the result of summing data that comes from different resources, but also from the amount of data that has increased during very long period. This brings along advantages, such as ability to explore long term dynamics and recurring seasonal changes, and constraints, such as disability to manage “changing” data such as status of payments. Data warehousing environment is planned to facilitate analyses of static data, which comes from different sources. Such data is logically and physically transformed, renewed and stored during long period, processed to meet the requirements of market analyses and expressed as simple data, which in conclusion enables fast data analyses.

Data warehousing systems (DWS) are often created as relational databases, which include some special attributes: • Database of data warehouse is different from the other databases, which recieve the data from different databases and such databases are also often housed in different servers. This aspect occurs first, because DWS integrates data coming from different databases and also because of efficiency consideration. If data is located in different databases or servers, then DWS and company’s database does not influence each other: operations of analyses which are performed by DWS does not enlarge the capacity for information system and vice versa. • DWS does not use any normal forms (see following clauses) even if it uses relational database for creating many expanded tables in order to simplify the analyses. DWS includes usually the following components: • Tools for accessing non-homogeneous data sources that are used during data warehouse completing phase; • "Completing" process that acquires data from homogeneous sources and prepares data for installing it to the supportive database. • Database with distinctness described above includes acquired data. • Multiple analyses’ processes, which are used for acquiring information from the database; • Some data mining processes which enable to acquire detailed information according to logical paths, which could also be quite complex due to the processes of previous analyses. DWS "completing" process, which regularly integrates the data acquired from different data sources, is very important. This process includes following steps: • Contrasting process to normalization. The purpose of contrasting process is to gather together a huge archive starting from more structured information. The archive of customers and payments can for example be connected up to one archive in order to show the data of each client together with every committed payment. This is inconsistent to the theory of relational database, which is the basic for creating the databases, but at the same time it helps to prepare the data for performing simpler analyses; • Removing variable elements. The purpose is to reduce "information pollution", which can compound following analyses. Information parts that change in time are called variable elements. Status of the payment is variable element, which has “no” value until it changes to “yes” value. Transfer (of payment) is not variable element, because once it is done it stays stored as it is. • Scrubbing. The purpose is to remove the mistakes, which derive from non complete data, name spelling mistakes, wrong location of the letters or numbers and linguistic changes, which can cause problems in phase of data analyses; • Nomenclature scrubbing. The purpose is to avoid duplicated information. Information comes from different sources and can be tagged differentially. • Type normalization. The purpose is to assure that information coming from different sources is in same format; • Management of “Null”-values. Null-value in databases corresponds to lack of information, which has to be handeled correctly during data insertion. • Creation of summarized data for hastening the following analyses. B.2.8.2 Data mining

Data mining is the process of sorting through large amounts of data and picking out relevant information. It is usually used by business intelligence organizations, and financial analysts, but is increasingly being used in the sciences to extract information from the enormous data sets generated by modern experimental and observational methods. It has been described as "the nontrivial extraction of implicit, previously unknown, and potentially useful information from data" and "the science of extracting useful information from large data sets or databases." Data mining in relation to enterprise resource planning is the statistical and logical analysis of large sets of transaction data, looking for patterns that can aid decision making

Traditionally, business analysts have performed the task of extracting useful information from recorded data, but the increasing volume of data in modern business and science calls for computer-based approaches. As data sets have grown in size and complexity, there has been a shift away from direct hands-on data analysis toward indirect, automatic data analysis using more complex and sophisticated tools. The modern technologies of computers, networks, and sensors have made data collection and organization much easier. However, the captured data needs to be converted into information and knowledge to become useful. Data mining is the entire process of applying computer-based methodology, including new techniques for knowledge discovery, to data

Data mining identifies trends within data that go beyond simple analysis. Through the use of sophisticated algorithms, non-statistician users have the opportunity to identify key attributes of business processes and target opportunities. However, abdicating control of this process from the statistician to the machine may result in false-positives or no useful results at all.

Although data mining is a relatively new term, the technology is not. For many years, businesses have used powerful computers to sift through volumes of data such as supermarket scanner data to produce market research reports (although reporting is not considered to be data mining). Continuous innovations in computer processing power, disk storage, and statistical software are dramatically increasing the accuracy and usefulness of data analysis. Web 2.0 technologies have generated a colossal amount of user-generated data and media, making it hard to aggregate and consume information in a meaningful way without getting overloaded. Given the size of the data on the Internet, and the difficulty in contextualizing it, it is unclear whether the traditional approach to data mining is computationally viable.

The term data mining is often used to apply to the two separate processes of knowledge discovery and prediction. Knowledge discovery provides explicit information that has a readable form and can be understood by a user. Forecasting, or predictive modelling provides predictions of future events and may be transparent and readable in some approaches (e.g., rule-based systems) and opaque in others such as neural networks. Moreover, some data-mining systems such as neural networks are inherently geared towards prediction and pattern recognition, rather than knowledge discovery.

Metadata, or data about a given data set, are often expressed in a condensed data-minable format, or one that facilitates the practice of data mining. Common examples include executive summaries and scientific abstracts.

Data mining relies on the use of real world data. This data is extremely vulnerable to collinearity precisely because data from the real world may have unknown interrelations. An unavoidable weakness of data mining is that the critical data that may expose any relationship might have never been observed. Alternative approaches using an experiment-based approach such as Choice Modelling for human-generated data may be used. Inherent correlations are either controlled for or removed altogether through the construction of an experimental design.

B.2.8.3 Application fields of DW and data mining systems

Games Since the early 1960s, with the availability of oracles for certain combinatorial games, also called table bases (e.g. for 3x3-chess) with any beginning configuration, small-board dots-and-boxes, small-board-hex, and certain endgames in chess, dots-and-boxes, and hex; a new area for data mining has been opened up. This is the extraction of human-usable strategies from these oracles. Current pattern recognition approaches do not seem to fully have the required high level of abstraction in order to be applied successfully. Instead, extensive experimentation with the tablebases, combined with an intensive study of tablebase-answers to well designed problems and with knowledge of prior art, i.e. pre-tablebase knowledge, is used to yield insightful patterns. Berlekamp in dots-and-boxes etc. and John Nunn in chess endgames are notable examples of researchers doing this work, though they were not and are not involved in tablebase generation.

Business Data mining in customer relationship management applications can contribute significantly to the bottom line. Rather than contacting a prospect or customer through a call centre or sending mail, only prospects that are predicted to have a high likelihood of responding to an offer are contacted. More sophisticated methods may be used to optimize across campaigns so that we can predict which channel and which offer an individual is most likely to respond to - across all potential offers. Finally, in cases where many people will take an action without an offer, uplift modeling can be used to determine which people will have the greatest increase in responding if given an offer. Data clustering can also be used to automatically discover the segments or groups within a customer data set. Businesses employing data mining quickly see a return on investment, but also they recognize that the number of predictive models can quickly become very large. Rather than one model to predict which customers will churn, a business could build a separate model for each region and customer type. Then instead of sending an offer to all people that are likely to churn, it may only want to send offers to customers that will likely take to offer. And finally, it may also want to determine which customers are going to be profitable over a window of time and only send the offers to those that are likely to be profitable. In order to maintain this quantity of models, they need to manage model versions and move to automated data mining. Data mining can also be helpful to human-resources departments in identifying the characteristics of their most successful employees. Information obtained, such as universities attended by highly successful employees, can help HR focus recruiting efforts accordingly. Additionally, Strategic Enterprise Management applications help a company translate corporate-level goals, such as profit and margin share targets, into operational decisions, such as production plans and workforce levels. Another example of data mining, often called the market basket analysis, relates to its use in retail sales. If a clothing store records the purchases of customers, a data-mining system could identify those customers who favour silk shirts over cotton ones. Although some explanations of relationships may be difficult, taking advantage of it is easier. The example deals with association rules within transaction-based data. Not all data are transaction based and logical or inexact rules may also be present within a database. In a manufacturing application, an inexact rule may state that 73% of products, which have a specific defect or problem will develop a secondary problem within the next six months.

Related to an integrated-circuit production line, an example of data mining is described in the paper (Fountain, 2000) In this paper the application of data mining and decision analysis to the problem of die-level functional test is described. Experiments mentioned in this paper demonstrate the ability of applying a system of mining historical die-test data to create a probabilistic model of patterns of die failure which are then utilized to decide in real time which die to test next and when to stop testing. This system has been shown, based on experiments with historical test data, to have the potential to improve profits on mature IC products.

Science and engineering In recent years, data mining has been widely used in area of science and engineering, such as bioinformatics, genetics, medicine, education, and electrical power engineering. In the area of study on human genetics, the important goal is to understand the mapping relationship between the inter-individual variation in human DNA sequences and variability in disease susceptibility. In lay terms, it is to find out how the changes in an individual's DNA sequence affect the risk of developing common diseases such as cancer. This is very important to help improve the diagnosis, prevention and treatment of the diseases. The data mining technique that is used to perform this task is known as multifactor dimensionality reduction. In the area of electrical power engineering, data mining techniques have been widely used for condition monitoring of high voltage electrical equipment. The purpose of condition monitoring is to obtain valuable information on the insulation's health status of the equipment. Data clustering such as self-organizing map (SOM) has been applied on the vibration monitoring and analysis of transformer on-load tap-changers. Using vibration monitoring, it can be observed that each tap change operation generates a signal that contains information about the condition of the tap changer contacts and the drive mechanisms. Obviously, different tap positions will generate different signals. However, there was considerable variability amongst normal condition signals for the exact same tap position. SOM has been applied to detect abnormal conditions and to estimate the nature of the abnormalities. Data mining techniques have also been applied for dissolved gas analysis (DGA) on power transformers. DGA, as a diagnostics for power transformer, has been available for centuries. Data mining techniques such as SOM has been applied to analyse data and to determine trends, which are not obvious to the standard DGA ratio techniques. A third area of application for data mining in science/engineering is within educational research, where data mining has been used to study the factors leading students to choose to engage in behaviours which reduce their learning. and to understand the factors influencing university student retention. Other examples of applying data mining technique applications are biomedical data facilitated by domain ontologies, mining clinical trial data, traffic analysis, et cetera.


7. Links to additional materials: Beynon-Davies, Paul (2004). Database Systems. Houndmills, Basingstoke, UK: Palgrave, 2004 Elmasri, R., Navathe, S. B. Fundamentals of Database Systems, Addison Wesley, 4th edition, 2004 Fountain, T., Dietterich, T., Sudyka, B. (2000) Mining IC test data to optimize VLSI testing. In Proceedings of the sixth ACM SIGKDD international conference on Knowledge discovery and data mining. Boston, Massachusetts, United States , pp 18 – 25.

8. Test Questions

Question 1 Is the average salary of 8049 EEK either data or information? Answer A) Data Answer B) Information

Question 2 Is the indicator of “average age” given by Department of Statistics the information? Answer A) Yes Answer B) No

Question 3 How is data stored in tables? Answer A) As records Answer B) As data sequence Answer C) As data stack

Question 4 What for is the data dictionary needed? Answer A) For reducing the data redundancy Answer B) For describing the data and tables Answer C) For data separation

Question 5 Attribute of well-designed database is: Answer A) Lack of redundancy Answer B) Integrity Answer C) Duplication

Question 6 Coherent functioning of well-designed database is granted by: Answer A) Referential integrity Answer B) Reduced duplication Answer C) Timely back up

Question 7 What does enable fast data searches in databases? Answer A) Using the indexes, i.e. indexing Answer B) Fast operation system Answer C) Enlarging the memory of operation system

8.1 Answers (correct and falses)

Question 1 Correct: Answer B) Information

Question 2 Correct: Answer A) Yes

Question 3 Correct: Answer A) As records

Question 4 Correct: Answer B) For describing the data and tables

Question 5 Correct: Answer A) Lack of redundancy

Question 6 Correct: Answer A) Referential integrity

Question 7) Correct: Answer A) Using indexes, i.e. indexing Partly correct: Answer B, Answer C


8.2. Feedback for answering

Question 1 Answer A) False, Given sentence is not in format understandable for PC. Answer B) Correct, number quantity is given in context of the average salary.

Question 2 Answer A) Correct, data is given in context of average age. Answer B) False, Department of Statistics does not give out the data in format understandable to PC.

Question 3 Answer A) Correct, data is stored as structured records. Answer B) False, data sequence does not enable to store data structured. Answer C) False, stack of data slows down the searches in databases.

Question 4 Answer A) False, reducing the data redundancy is the task of database designer. Answer B) Correct! Answer C) False, data dictionary is for storing the metadata. Question 5 Answer A) Correct, Lack of redundancy is the attribute of well-designed database Answer B) False! Answer C) False! Question 6 Answer A) Correct! Answer B) False, reduced duplication does not impact on the coherent functioning. Answer C) False, Timely back up does not impact on the coherent functioning.

Question 7 Answer A) Correct! Answer B) Partly correct – indexing gives better result. Answer C) Partly correct – indexing gives better result.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.