Databases Samenvatting

Transcriptie

1 Databases Samenvatting Dieter Castel Jonas Devlieghere Karel Domin Giel Dops Dennis Frett Kevin Fockaert Kenneth Geets John Gybels Laurent Janssens Ben Lefevere 13 januari 2015

2 Inhoudsopgave 1 Introduction to Databases Introduction An Example Characteristics of the Database Approach Self-Describing Nature of a Database System Insulation between Programs and Data, and Data Abstraction Support of Multiple Views of the Data Sharing of Data and Multiuser Transaction Processing Actors on the Scene Database Administrators Database Designers End Users System Analysts and Application Programmers (Software Engineers) Workers behind the Scene Advantages of Using the DBMS Approach Controlling Redundancy Restricting Unauthorized Access Providing Persistent Storage for Program Objects Providing Storage Structures and Search Techniques for Efficient Query Processing Providing Backup and Recovery Providing Multiple User Interfaces Representing Complex Relationships among Data Enforcing Integrity Constraints Permitting Inferencing and Actions Using Rules Additional Implications of Using the Database Approach When Not to Use a DBMS Overview of Database Languages and Architectures Data Models, Schemas, and Instances Categories of Data Models Schemas, Instances and Database State Three-Schema Architecture and Data Independence The Three-Schema Architecture Data Independence Database Languages and Interfaces DBMS Languages DBMS Interfaces The Database System Environment DBMS Component Modules

3 2.4.2 Database System Utilities Tools, Application Environments, and Communications Facilities Centralized & Client/Server Architectures for DBMSs Centralized DBMSs Architecture Basic Client/Server Architectures Two-Tier Client/Server Architectures for DBMSs Three-Tier and n-tier Architectures for Web Applications Classification of Database Management Systems The Basic (Flat) Relational Model Relational Model Concepts Domains, Attributes, Tuples, and Relations Characteristics of Relations Relational Model Notation Relational Model Constraints and Relational Database Schemas Domain Constraints Key Constraints and Constraints on NULL values Relational Databases and Relational Database Schemas Integrity, Referential Integrity and Foreign Keys Other Types of Constraints Update Operations, Transactions and Dealing with Constraint Violations The Insert Operation The Delete Operation The Update Operation The Transaction Concept SQL: Data Definition, Constraints, and Basic Queries and Updates SQL Data Definition and Data Types Schema and Catalog Concepts in SQL The CREATE TABLE Command in SQL Attribute Data Types and Domains in SQL Specifying Constraints in SQL Specifying Attribute Constraints and Attribute Defaults Specifying Key and Referential Integrity Constraints Giving Names to Constraints Specifying Constraints on Tuples Using CHECK Basis Retrieval Queries in SQL The SELECT-FROM-WHERE Structure of Basic SQL Queries Ambiguous Attribute Names, Aliasing, Renaming, and Tuple Variables Unspecified WHERE Clause and Use of the Asterisk Tables as Sets in SQL Substring Pattern Matching and Arithmetic Operators Ordering of Query Results Discussion and Summary of Basic SQL Retrieval Queries INSERT, DELETE, and UPDATE Statements in SQL The INSERT Command The DELETE Command The UPDATE Command Additional Features of SQL

4 5 SQL: Advanced Queries, Assertions, Triggers, and Views More Complex SQL Retrieval Queries Comparisons Involving NULL and Three-Valued Logic Nested Queries, Tuples, and Set/Multiset Comparisons Correlated Nested Queries The EXISTS and UNIQUE Functions in SQL Explicit Sets and Renaming of Attributes in SQL Joined Tables in SQL and Outer Joins Aggregate Functions in SQL Grouping: The GROUP BY and HAVING Clauses Specifying Constraints as Assertions and Actions as Triggers Specifying General Constraints as Assertions in SQL Introduction to Triggers in SQL Views (Virtual Tables) in SQL Concept of a View in SQL Specification of Views in SQL View Implementation, View Update, and Inline Views Schema Change Statements in SQL The DROP Command The ALTER Command Formal Relational Languages: The Algebra and Calculus Unary Relational Operations: SELECT & PROJECT The SELECT Operation The PROJECT Operation Sequences of Operations and the RENAME Operation Relational Algebra Operations from Set Theory The UNION, INTERSECTION, and MINUS Operations The CARTESIAN PRODUCT (CROSS PRODUCT) Operation Binary Relational Operations: JOIN and DIVISION The JOIN Operation Variations of JOIN: The EQUIJOIN and NATURAL JOIN A Complete Set of Relational Algebra Operations The DIVISION Operation Notation for Query Trees Additional Relational Operations Generalized Projection Aggregate Functions and Grouping Recursive Closure Operations OUTER JOIN Operations The OUTER UNION Operation The Tuple Relational Calculus Tuple Variables and Range Relations Expressions and Formulas in Tuple Relational Calculus The Existential and Universal Quantifiers Sample Queries in Tuple Relational Calculus Notation for Query Graphs Transforming the Universal and Existential Quantifiers Using the Universal Quantifiers in Queries Safe Expressions

5 6.7 The Domain Relational Calculus Conceptual Data Modeling Using Entities and Relationships Using High-Level Conceptual Data Models for Database Design Entity Types, Entity Sets, Attributes, and Keys Entities and Attributes Entity Types, Entity Sets, Keys, and Value Sets Relationship Types, Relationship Sets, Roles & Structural Constraints Relationship Types, Sets and Instances Relationship Degree, Role Names, and Recursive Relationships Constraints on Binary Relationship Types Attributes of Relationship Types Weak Entity Types ER Diagrams, Naming Conventions, and Design Issues Summary of Notation for ER Diagrams Proper Naming of Schema Constructs Design Choices for ER Conceptual Design Alternative Notations for ER Diagrams Relationship Types of Degree Higher than Two Choosing between Binary and Ternary (or Higher-Degree) Relationships Constraints on Ternary (or Higher-Degree) Relationships Subclasses, Superclasses, and Inheritance Specialization and Generalization in EER Specialization Generalization Constraints and Characteristics of Specialization and Generalization Hierarchies Constraints on Specialization and Generalization Specialization and Generalization Hierarchies and Lattices Utilizing Specialization and Generalization in Refining Conceptual Schemas Modeling of UNION Types Using Categories in EER A Sample UNIVERSITY EER Schema, Design Choices, and Formal Definitions The UNIVERSITY Database Example Design Choices for Specialization/Generalization Data Abstraction, Knowledge Representation, & Ontology Concepts Classification and Instantiation Identification Specialization and Generalization Aggregation and Association Ontologies and the Semantic Web Mapping a Conceptual Design into a Logical Design Relational Database Design using ER-to-Relational Mapping ER-to-Relational Mapping Algorithm Discussion and Summary of Mapping for ER Model Constructs Mapping EER Model Constructs to Relations Mapping of Specialization or Generalization Mapping of Shared Subclasses (Multiple Inheritance) Mapping of Categories (Union Types)

6 12 SQL Application Programming Using C and Java Database Programming: Techniques and Issues Approaches to Database Programming Impedance Mismatch Typical Sequence of Interaction in Database Programming SQL Web Programming Using C PHP A Simple PHP Example Overview of Basic Features of PHP PHP Variables, Data Types, and Programming Constructs PHP Arrays PHP Functions PHP Server Variables and Forms Overview of PHP Database Programming Connecting to a Database Collecting Data from Forms and Inserting Records Retrieval Queries from Database Tables Database Design Theory: Introduction to Normalization Using Functional and Multivalued Dependencies Informal Design Guidelines for Relation Schemas Imparting Clear Semantics to Attributes in Relations Redundant Information in Tuples and Update Anomalies NULL values in Tuples Generation of Spurious Tuples Summary and Discussion of Design Guidelines Functional Dependencies Definition of Functional Dependency Normal Forms Based on Primary Keys Normalization of Relations Practical Use of Normal Forms Definitions of Keys and Attributes Participating in Keys First Normal Form Second Normal Form Third Normal Form General Definitions of Second & Third Normal Forms Boyce-Codd Normal Form Database Design Theory: Normalization Algorithms Further Topics in Functional Dependencies: Inference Rules, Equivalence, and Minimal Cover Inference Rules for Functional Dependencies Equivalence of Sets of Functional Dependencies Minimal Sets of Functional Dependencies Properties of Relational Decompositions Dependency Preservation Property of a Decomposition Nonadditive (Lossless) Join Property of a Decomposition Testing Binary Decompositions for the Nonadditive Join Property Successive Nonadditive Join Decompositions Algorithms for Relational Database Schema Design

7 Dependency-Preserving Decomposition into 3NF Schemas Nonadditive Join Decomposition into BCNF Schemas Dependency-Preserving and Nonadditive (Lossless) Join Decomposition into 3NF Schemas About Nulls, Dangling Tuples, and Alternative Relational Designs Problems with NULL Values and Dangling Tuples Discussion of Normalization Algorithms and Alternative Relational Designs Database File Organizations: Unordered, Ordered, and Hashed Files of Records Introduction Memory Hierarchies and Storage Devices Storage of Databases Secondary Storage Devices Buffering of Blocks Placing File Records on Disk Records and Record Types Files, Fixed-length Records, and Variable-Length Records Record Blocking and Spanned versus Unspanned Records Allocating File Blocks on Disk File Headers Operations on Files Files of Unordered Records (Heap Files) Files of Ordered Records (Sorted Files) Hashing Techniques Internal Hashing External Hashing for Disk Files Hashing Techniques That Allow Dynamic File Expansion Other Primary File Organizations Files of Mixed Records Parallelizing Disk Access Using RAID Technology New Storage Systems Storage Area Networks Network-Attached Storage iscsi Storage Systems Database File Indexing Techniques, B-Trees, and B+-Trees Types of Single-Level Ordered Indexes Primary Indexes Clustering Indexes Secondary Indexes Multilevel Indexes Dynamic Multilevel Indexes Using B-trees & B+-Trees Search Trees and B-trees B+-trees Indexes on Multiple Keys Ordered Index on Multiple Attributes Partitioned Hashing Grid Files Other Types of Indexes Hash Indexes

8 Bitmap Indexes Function-Based Indexing Some General Issues Concerning Indexing Logical versus Physical Indexes Discussion Column-Based Storage of Relations Introduction to Query Processing and Query Optimization Techniques Translating SQL Queries into Relational Algebra Algorithms for External Sorting Algorithms for SELECT and JOIN Operations Implementing the SELECT Operation Implementing the JOIN Operation Algorithms for PROJECT and Set Operations Implementing Aggregate Operations and OUTER JOINs Implementing Aggregate Operations Implementing OUTER JOINs Combining Operations Using Pipelining Using Heuristics in Query Optimization Notation for Query Trees and Query Graphs Heuristic Optimization of Query Trees Converting Query Trees into Query Execution Plans Using Selectivity and Cost Estimates in Query Optimization Cost components for Query Execution Catalog Information Used in Cost Functions Examples of Cost Functions for SELECT Examples of Cost Functions for JOIN Multiple Relation Queries and JOIN Ordening Example to Illustrate Cost-Based Query Optimization Overview of Query Optimization in Oracle Semantic Query Optimization Foundations of Database Transaction Processing Introduction to Transaction Processing Single-User versus Multiuser Systems Transactions, Database Items, Read and Write Operations, and DBMS Buffers Why Concurrency Control Is Needed Why Recovery Is Needed Transaction and System concepts Transaction States and Additional Operations The System Log Commit Point of a Transaction Desirable Properties of Transactions Characterizing Schedules Based on Recoverability Schedules (Histories) of Transactions Characterizing Schedules Based on Recoverability Characterizing Schedules Based on Serializability Serial, Nonserial, and Conflict-Serializable Schedules Testing for Conflict Serializability of a Schedule How Serializability Is Used for Concurrency Control

9 View Equivalence and View Serializability Other Types of Equivalence of Schedules Transaction Support in SQL Introduction to Protocols for Concurrency Control in Databases Two-Phase Locking Techniques for Concurrency Control Types of Locks and System Lock Tables Guaranteeing Serializability by Two-Phase Locking Dealing with Deadlock and Starvation Concurrency Control Based on Timestamp Ordering Timestamps The Timestamp Ordering Algorithm Multiversion Concurrency Control Techniques Multiversion Technique Based on Timestamp Ordering Multiversion Two-Phase Locking Using Certify Locks Validation (Optimistic) Concurrency Control Techniques Granularity of Data Items and Multiple Granularity Locking Granularity Level Considerations for Locking Multiple Granularity Level Locking Using Locks for Concurrency Control in Indexes Other Concurrency Control Issues Insertion, Deletion, and Phantom Records Interactive Transactions Latches Introduction to Database Recovery Protocols Recovery Concepts Recovery Outline and Categorization of Recovery Algorithms Caching (Buffering) of Disk Blocks Write-Ahead Logging, Steal/No-Steal, and Force/No-Foce Checkpoints in the System Log and Fuzzy Checkpoints Transaction Rollback and Cascading Roll back Transactions Actions That Do Not Affect the Database NO-UNDO/REDO Recovery Base on Deffered Update Recovery Rechniques Based on Immediate Update Shadow Paging Before Transaction During Transaction Recovery Process Disadvantages The Aries Recovery Algorithm Analysis Phase REDO Phase UNDO Phase Structures Log Sequence Number (LSN) Tables Checkpoints Recovery from crash Recovery in Multidatabse Systems

10 22.7 Database Backup and Recovery from Catastrophic Failures Handling more Catastrophic Failures Increase frequency

11 Hoofdstuk 1 Introduction to Databases 1.1 Introduction Een database heeft volgende eigenschappen: Het is een representatie van een aspect in de echte wereld, een miniwereld, ook wel universe of discourse (UoD) genaamd. Een database is een verzameling van gerelateerde informatie/data. Een database wordt ontworpen, gebouwd en ingevuld voor een specifiek doel. Aanpassingen moeten zo snel mogelijk weergegeven worden in de database. Een database management system (DBMS) is een set van programma s die de gebruiker toelaat een database te creëren en te onderhouden. 1.2 An Example Het manipuleren van een database omvat querying en updating. Een query moet gespecifieerd zijn in een bepaalde query-taal, behorende tot het DBMS, alvorens hij kan worden uitgevoerd. 1. Het ontwikkelen van een applicatie voor een bestaande database, of het ontwikkelen van een compleet nieuwe database start met een fase genaamd requirements specification and analysis. De eisen/voorwaarden van de database worden hier in detail vastgelegd. 2. De eisen/voorwaarden worden omgevormd tot een conceptual design dat weergegeven en bewerkt kan worden op een computer. 3. Het conceptual design wordt omgezet naar een logical design, dat geïmplementeerd kan worden in een commercieel DBMS. 4. Het logical design wordt omgezet in een physical design, waar men de verdere specificaties voor opslag en toegang tot de database zal vastleggen. Hierna kan men beginnen de database te bevolken. 10

12 1.3 Characteristics of the Database Approach Een database bestaat uit een enkele opslagplaats waar gegevens worden bijgehouden die één keer gedefinieerd worden en nadien toegankelijk zijn voor alle gebruikers Self-Describing Nature of a Database System Een basiskenmerk van een databasesysteem is dat het systeem niet enkel de database zelf bevat maar ook een complete definitie of beschrijving van de databasestructuur en zijn beperkingen. Deze definitie wordt bijgehouden in de DBMS catalogus. De informatie in deze catalogus is de zogenaamde meta-data, en beschrijft de structuur van de primaire database Insulation between Programs and Data, and Data Abstraction In traditionele bestandsverwerking is de structuur van de data files ingebouwd in het programma dat gebruik maakt van het bestand. Als de structuur van een bestand gewijzigd wordt, zullen dus ook alle programma s die gebruik maken van het bestand, aangepast moeten worden. Een DBMS daarentegen bewaart de structuur van de bestanden in de catalogus, apart van de programma s die het gebruiken. We noemen dit program-data independence. Een operation (functie of methode) bestaat uit 2 delen. De interface (signature) van een operatie bevat de naam van de operatie en de data types van zijn argumenten (parameters). De implementatie van de operatie is apart gedefinieerd en kan aangepast worden zonder dat de interface gewijzigd moet worden. Gebruikersprogramma s kunnen met de data werken door middel van operatienamen en -parameters, onafhankelijk van hoe de operaties geïmplementeerd zijn. We noemen dit programoperation independence. De karakteristiek die program-data independence en program-operation independence toelaat, wordt de data abstraction genoemd. Een data model is een soort van data abstraction die voor een conceptual representation van de data zorgt Support of Multiple Views of the Data Een database heeft vaak meerdere gebruikers die eventueel een ander zicht (view) willen op de database. Een view kan een subset van de database zijn maar het kan ook zelf virtuele data bevatten die afgeleid is van de data in de database maar er niet opgeslagen is Sharing of Data and Multiuser Transaction Processing Een multiuser DBMS moet toelaten dat meerdere gebruikers tegelijkertijd toegang hebben tot de database. Hiervoor moet de DBMS over concurrency control software beschikken om te verzekeren dat het updaten van data door meerdere gebruikers correct verloopt zodat ook het resultaat hiervan correct is. Een transactie is een uitvoerend programma of proces dat één of meerdere database accesses omvat. De isolation-eigenschap verzekert dat elke transactie uitgevoerd wordt, afgezonderd van andere transacties. De atomicity-eigenschap verzekert dat alle transacties ofwel volledig uitgevoerd worden, ofwel niet uitgevoerd worden. 11

13 1.4 Actors on the Scene Actors on the scene zijn de personen die dagelijks een grote database gebruiken Database Administrators Er is nood aan een chief administrator, we noemen deze de database administrator (DBA). Hij is verantwoordelijk voor autorisatie, coördinatie, monitoring en de software en hardware resources. Hij is ook de persoon die verantwoordelijk gesteld kan worden voor problemen zoals veiligheidslekken en een slechte responstijd van het systeem Database Designers Database designers zijn de personen die verantwoordelijk zijn voor het identificeren van de data die opgeslagen moet worden op de database en voor het kiezen van de juiste datastructuren om deze op te slagen data voor te stellen in de database End Users Eindgebruikers zijn de personen wiens job eruit bestaat een database te bevragen, up te daten en rapporten te maken. We kunnen ze onderverdelen in verschillende categorieën: Casual end users hebben de database occasioneel nodig en hebben mogelijk elke keer andere gegevens nodig. Naive of parametric end users bevragen en updaten de database constant. Sophisticated end users (zoals ingenieurs of wetenschappers) kennen de eigenschappen en mogelijkheden van de database zeer goed zodat ze hun eigen applicaties kunnen implementeren. Standalone users hebben meestal een persoonlijke database System Analysts and Application Programmers (Software Engineers) System analysts bepalen de eisen van de eindgebruiker en ontwerpen de specificaties voor alleenstaande transacties die voldoen aan deze eisen. Application programmers implementeren deze specificaties als programma s die ze testen, debuggen en documenteren. 1.5 Workers behind the Scene Dit stuk gaat over de mensen die de DBMS software en system environment ontwerpen, ontwikkelen en de operaties ervan uitschrijven. Ze zijn meestal niet geïnteresseerd in de inhoud van de database. DBMS system designers en implementers ontwerpen en implementeren de DBMS modules en interfaces als een softwarepakket. Tool developers ontwerpen en implementeren tools. Tools zijn optionele pakketten die vaak apart aangekocht kunnen worden. Operators en maintenance personnel is het system administration personnel. Ze zijn verantwoordelijk voor het runnen en het onderhoud van de hardware en software environment. 12

14 1.6 Advantages of Using the DBMS Approach Controlling Redundancy De redundantie is het meermaals opslaan van dezelfde data, dit leidt tot verschillende problemen. Een simpele update moet meerdere malen uitgevoerd worden, dit is duplication of effort. Opslagruimte wordt verspilt. Bestanden die dezelfde data voorstellen kunnen inconsistent worden omdat een update niet wordt doorgevoerd op alle bestanden. We moeten een database hebben die elk logical data item (bv. naam en geboortedatum) opslaat op één enkele plaats in de database, dit heet data normalization. Soms is er echter nood aan gecontroleerde redundantie. Dit komt voor indien we alle data die vaak samen opgevraagd wordt, in 1 bestand plaatsen. Hierdoor moet er bij een query slechts 1 bestand doorzocht worden i.p.v. meerdere. Dit heet denormalization Restricting Unauthorized Access Als meerdere gebruikers een grote database delen, is het logisch dat niet iedereen toegang heeft tot alle data. Een DBMS moet een security and authorization subsystem bevatten, waarmee de DBA accounts kan aanmaken en restricties kan opleggen Providing Persistent Storage for Program Objects Databases kunnen gebruikt worden om persistente opslag voor programma-objecten en datastructuren aan te bieden. Dit is één van de redenen voor object-oriented database systems. Een complex object in C++ kan permanent opgeslagen worden in een object-georiënteerd DBMS. Zo een object noemen we persistent, omdat het de beëindiging van het programma overleeft en later direct kan teruggevonden worden Providing Storage Structures and Search Techniques for Efficient Query Processing Databasesystemen moeten de mogelijkheid hebben tot het efficiënt uitvoeren van query s en updates. Omdat een database vaak is opgeslagen op een disk, moet de DBMS speciale datastructuren en technieken voorzien om de seektime te versnellen. Een oplossing hiervoor is werken met indexering. Een DBMS biedt vaak buffering of caching modules aan, die bijgehouden worden in het hoofdgeheugen. De query processing and optimization module is verantwoordelijk voor het kiezen van een efficiënt query-uitvoeringsplan voor elke query, gebaseerd op de huidige opslagstructuur Providing Backup and Recovery Een DBMS moet de mogelijkheid bezitten om te herstellen van hardware- of softwarefouten. Het backup and recovery subsystem van de DBMS is verantwoordelijk voor het herstel. Het moet kunnen herstellen, hervatten of een backup maken. 13

15 1.6.6 Providing Multiple User Interfaces Dit omvat query-talen voor casual users, programming language interfaces voor application programmers, formulieren en commando s voor parametric users en menu-gestuurde interfaces en natural language interfaces voor standalone users. Vaak in combinatie met een GUI Representing Complex Relationships among Data Een DBMS moet de mogelijkheid bieden om complexe relaties tussen data voor te stellen, evenals de mogelijkheid om nieuwe relaties te definiëren en gerelateerde data snel en efficiënt terug te vinden Enforcing Integrity Constraints De meeste database applications hebben bepaalde integrity constraints die moeten gelden voor de data. Een DBMS moet de mogelijkheid bieden om constraints te definiëren en ze te handhaven Permitting Inferencing and Actions Using Rules Sommige databasesystemen hebben de mogelijkheid om informatie af te leiden uit reeds bestaande data. Zulke systemen noemen we deductive database systems. In moderne databases bestaat de mogelijkheid om triggers te associëren met tabellen. Een trigger is een soort regel die toegepast wordt bij een update op een tabel, wat resulteert in het uitvoeren van extra operaties zoals het sturen van een boodschap. Nog sterker zijn active database systems, deze leveren actieve regels die automatisch acties uitvoeren wanneer bepaalde gebeurtenissen of condities voorkomen Additional Implications of Using the Database Approach Potential for Enforcing Standards: de DBA wordt toegelaten om een bepaalde standaard te definiëren voor de users. Reduced Application Development Time: eens een database is opgezet en runt, is er minder tijd nodig om een nieuwe applicatie te ontwikkelen, gebruikmakend van de DBMS mogelijkheden. Flexibility: moderne DBMS en laten verschillende soorten van evolutionaire veranderingen toe in de structuur van de database zonder invloed op de opgeslagen data of applicaties. Availability of Up-to-Date information: vanaf het moment dat een gebruiker bepaalde data heeft geüpdatet, moeten deze wijzigingen zichtbaar zijn voor andere gebruikers. Economies of Scale: systemen kunnen gedeeld worden om overlappingen te voorkomen op verschillende niveaus. 1.8 When Not to Use a DBMS Er zijn bepaalde situaties waarbij het gebruik van een DBMS een onnodige overhead kan veroorzaken, wat niet zou voorkomen bij het traditionele file processing. De overhead van een DBMS kan volgende oorzaken hebben: Te hoge initiële kosten voor hardware, software en training De algemeenheid van een DBMS Overhead voor het leveren van security, concurrency en recovery 14

16 Hoofdstuk 2 Overview of Database Languages and Architectures DBMS packages zijn gegroeid van één geïntegreerd systeem naar modulaire systemen. Deze bestaan uit verschillende delen. Standaard wordt er gewerkt met twee modules: een client module die de gebruikersinteractie moet verzorgen en een server module die zaken als dataopslag, toegang, en het doorzoeken van de database op zich neemt. 2.1 Data Models, Schemas, and Instances Een belangrijk kenmerk van databases is dat ze een soort van data abstraction voorzien. Hiermee bedoelt men dat zaken als de schijfopslag van de data worden genegeerd, terwijl enkel het belangrijkste om de data te kunnen bestuderen en interpreteren wordt getoond. Er worden ook meer en meer hoogniveau operaties geïmplementeerd zodat manipulatie of interpretatie van de opgeslagen data zo eenvoudig mogelijk wordt. Dit wordt ook wel het dynamische aspect van de database genoemd Categories of Data Models Er zijn een drietal interessante, veel voorkomende datamodellen: Hoog-niveau of conceptuele datamodellen Deze datamodellen gebruiken concepten als entiteiten, attributen en relaties: een entiteit stelt een object uit de echte wereld voor een attribuut stelt een eigenschap van zo een entiteit voor een relatie stelt een associatie voor tussen twee of meer entiteiten Representatieve of implementatie-datamodellen Deze datamodellen worden in commerciële databasesystemen het vaakst gebruikt. Ze maken gebruik van relaties, maar ook van record structures. Laag-niveau of fysieke datamodellen Deze datamodellen beschrijven hoe data in bestanden wordt opgeslagen in het geheugen door informatie als het recordformaat, recordsortering en toegangspaden te beschrijven. 15

17 2.1.2 Schemas, Instances and Database State Er moet bij elk datamodel een onderscheid gemaakt worden tussen de beschrijving van een database en de database zelf. De beschrijving van een database gebeurt in een database schema, ook wel een schema-diagram genoemd. Dit schema wordt ontwikkeld vóór het maken van de database en wordt niet dikwijls gewijzigd. Dit diagram geeft dus eigenlijk de structuur (de tabellen en hun kolomhoofden) weer van een database. De eigenlijke data van een database verandert regelmatig d.m.v. manipulaties. Elke momentopname in de tijd van de data in een database heet de database state (databasetoestand of instantie). Je kan het ook als volgt beschrijven: het schema is de intensie van de database, terwijl een databasetoestand een extensie van dit schema is. 2.2 Three-Schema Architecture and Data Independence De 3-schema architectuur probeert de volgende drie kenmerken te bereiken en visualiseren: Een catalog gebruiken om het schema in op te slaan zodat de database zelfbeschrijvend wordt. Isolatie tussen programma s en opgeslagen data. Ondersteunen van meerdere user views (manieren om de data te kunnen interpreteren) The Three-Schema Architecture In deze architectuur kunnen schema s op drie niveaus gedefiniëerd worden: Het interne niveau heeft een intern schema dat de fysische opslagstructuur en de toegangspaden beschrijft. Het conceptuele niveau heeft een conceptueel schema (implementatiemodel) dat de structuur van de database weergeeft voor gebruikers. Het externe niveau of view niveau heeft een aantal user views (hoe gebruikers data zien). Deze niveaus moeten uiteraard kunnen samenwerken. Bij het opvragen van data moet deze data aangepast worden om binnen de view van een zekere gebruik te passen. Deze transformaties tussen de verschillende niveaus heten mappings Data Independence Data independence binnen de 3-schema architectuur houdt in dat je het schema van één niveau kan veranderen zonder dat je het schema van het niveau direct daarboven moet aanpassen. Er zijn twee types: Logical data independence houdt in dat je het conceptueel schema kan aanpassen zonder dat je daarvoor de externe schema s of applicaties moet voor aanpassen. Je moet dus de structuur kunnen aanpassen en constraints kunnen definiëren zonder dat je daarvoor een aanpassing moet doen aan die externe schema s of applicaties. Physical data independence betekent dat je het intern schema kan aanpassen, zonder dat je aan het conceptueel schema dat er boven draait moet moet raken. De laatste soort onafhankelijkheid komt in de meeste databases wel voor, maar de eerste soort is iets moeilijker te verkrijgen. 16

18 2.3 Database Languages and Interfaces DBMS Languages Er zijn 4 theoretische DBMS-talen die belangrijk zijn voor de goede werking van de database: De data definition language (DDL) wordt gebruikt om de conceptuele en interne schema s te definiëren. De storage definition language (SDL) specificieert het interne schema. De view definition language (VDL) bepaalt de user views en de mappings die ze hebben naar het conceptueel schema. De data manipulation language (DML) staat in voor het manipuleren van data: opvragen, toevoegen, verwijderen of aanpassen. Deze zijn theoretisch omdat men in de praktijk niet werkt met aparte talen: alles wordt in één geïntegreerde taal gedefinieerd. Er zijn 2 soorten DMLs: high-level en low-level. Waar een high-level DML op zichzelf kan steunen om query s en dergelijke te processen (het wordt dan ook vaak query-taal genoemd), moet een low-level DML ingebouwd worden in een algemene programeertaal om gebruik te kunnen maken van hun functies zoals loops. In dit laatste geval is de low-level taal een data sublanguage van de host language, de programmeertaal waarin de low-level taal geschreven is DBMS Interfaces Volgende interfaces kunnen in de database aanwezig zijn: Menu-Based Interfaces for Web Clients or Browsing. Deze interfaces worden gebruikt om de inhoud van de database te kunnen opvragen en bekijken met behulp van drop-down menu s. Forms-Based Interfaces. Deze interfaces maken gebruik van invulvelden om data op te vragen of om nieuwe data toe te voegen. Graphical User Interfaces. Dit type interfaces maakt gebruik van de twee voorgaande methodes om een nette interface te geven aan de gebruikers. Natural Language Interfaces. Hier wordt geprobeerd ingegeven woorden uit een spreektaal te vertalen zodat de zin kan geïnterpreteerd worden. Dit heet dan keyword-based querying. Speech Input and Output. Hierbij kan men via gesproken taal een query ingeven, het resultaat wordt door de computer ook in gesproken taal gegeven. Interfaces for Parametric Users. Interfaces voor gebruikers die een beperkte set commando s bij herhaling nodig hebben. Door hier een specifieke set van commando s in te voeren moeten er minder toetsen worden ingedrukt. Interfaces for the DBA. Uiteraard moeten ook de database administrators in staat zijn de database te kunnen manipuleren. Zij hebben daar deze specifieke interfaces voor. 17

19 2.4 The Database System Environment DBMS Component Modules Elke database en zijn catalogus is opgeslagen op een schijf. Toegang tot deze schijf wordt geregeld door het besturingssysteem. Daar zit uiteraard ook buffer management ingebakken om disk read/write operations te schedulen. Bovendien is er nog een stored data manager die de toegang tot informatie over het systeem beheert. Het user-gedeelte van de database bestaat uit de toegang voor de DBA staff, casual users, application programmers en parametric users. Het query and transactie-gedeelte staat in voor het uitvoeren van queries op de data en het teruggeven van het resultaat. Dit gebeurt in de runtime database processor, gebruikmakend van de system catalog en de stored data manager. Voordat de query wordt uitgevoerd is deze reeds gecompiled en geoptimaliseerd door de desbetreffende modules in het user-gedeelte. Zie eventueel figuur 2.3 op pagina Database System Utilities Elke database heeft een aantal system utilities die helpen bij het beheer van de database: Loading. Deze utility staat in voor het inladen van bestaande data files in een bepaald formaat (bv. tekstbestanden of sequentiële bestanden) in de database. Backup. Deze tool maakt een gehele backup van de database om de data te kunnen herstellen bij een disk failure. Soms werkt deze tool met incrementele backup waarbij enkel de veranderingen sinds de laatste toestand worden opgeslagen. Database storage reorganisation. Een tool om een set data te reorganiseren in files of in een ander pad in de database. Performance monitoring. Deze utility houdt het gebruik van de database bij en maakt er statistieken van die door de administrators kunnen geïnterpreteerd worden Tools, Application Environments, and Communications Facilities Er zijn nog een aantal extra tools die handig kunnen zijn, bijvoorbeeld een information repository. Hierin worden zaken als ontwerpsbeslissingen bijgehouden. Er is vaak ook communication software nodig om vanop afstand aan de database te kunnen. 2.5 Centralized & Client/Server Architectures for DBMSs Centralized DBMSs Architecture De eerste databases werden gebouwd als mainframes met daarop aangesloten terminals, deze terminals hadden geen eigen rekenkracht. Omdat hardware goedkoper werd, begon men de terminals te vervangen door PC s en werkstations waarbij het hele DBMS nog steeds centraal draaide. 18

20 2.5.2 Basic Client/Server Architectures Dit type architectuur werd ontwikkeld om te kunnen werken in omgevingen met een groot aantal PC s, werkstations, printers en allerhande servers. Het idee is om verscheidene servers specifieke taken te geven in plaats van alles zomaar te centraliseren. Server-side wordt alles verdeeld over verschillende types servers (printservers, fileservers, webservers,... ). Daarnaast is er ook de client-side, waarbij elke machine zijn gebruiker voorziet van de nodige interfaces om met deze servers te kunnen werken. Al deze servers en machines zijn onderling verbonden via een communicatienetwerk Two-Tier Client/Server Architectures for DBMSs Een 2-tier client/server architecture is rechtstreeks gegroeid uit de gecentraliseerde architectuur. Interfaces en applicatieprogramma s werden verhuisd van server- naar client-side. De server heet in zo n 2-tier systeem vaak de query server of transaction server omdat dit de functies van de server zijn. Client-side is er een programma dat via een API met de database kan verbinden en er query s kan op uitvoeren binnen de rechten die toegekend zijn aan de client. De softwarecomponenten zijn dus over 2 soorten systemen verdeeld zijn: clients en servers Three-Tier and n-tier Architectures for Web Applications Veel webapplicaties werken tegenwoordig met een 3-tier architecture. Er wordt een extra laag ingebouwd tussen client en server: een application server of web server. Deze server draait de applicatieprogramma s en slaat procedures en constraints op waarmee men rekening mee moet houden bij het opvragen van data van de database server. Deze middle-tier geldt ook als extra veiligheidsmaatregel: je kan een client verifiëren voor je zijn query doorstuurt naar de databaseserver. Op de client-layer zijn dan de gebruikers- en webinterfaces aanwezig, terwijl op de server alle data management services aanwezig zijn. De verschillende layers kunnen nog verder uit mekaar gehaald worden tot n-tier architectures, bijvoorbeeld een encryptie-/decryptieserver om communicatie van en naar de servers te beveiligen. 2.6 Classification of Database Management Systems Om DBMSs te classificeren zijn er een zestal criteria om te beschouwen: Het gebruikte datamodel. In veel DBMSs is dat het relationele datamodel. Aantal ondersteunde gebruikers. Een single-user system ondersteunt maar één gebruiker tegelijk, een multiuser system meerdere. Aantal plaatsen waarover de database verdeeld is. Een DBMS is gecentraliseerd als de data op één plaats staat en gedistribueerd als de data verspreid is over meerdere plaatsen. Kost. Er zijn gratis systemen zoals MySQL en PostgreSQL maar er zijn ook betalende systemen. Veel geld gaat meestal uit naar het onderhoud van de systemen en ondersteuning als er problemen zijn. De prioriteiten liggen hier voor particulieren anders dan voor bedrijven. Het gekozen type access path. Men gebruikt meestal geïnverteerde bestandstructuren. Het doel. Er zijn databases voor algemene doeleinden en voor speciale doeleinden. 19