Opsummering.

Slides:



Advertisements
Lignende præsentationer
VIS HJÆLPELINJER SOM ER EN HJÆLP VED PLACERING AF LOGO: 1.Højreklik på den aktuelle side og vælg ’gitter og hjælpelinjer’ 2. Sæt kryds ved ’Vis’ tegnehjælpelinjer.
Advertisements

Indsæt nyt billede: Format: B 254 x 190,5 mm Efter indsættelse, højreklik på billedet og placér det bagerst. Delete det gamle foto Legal aid in Denmark.
Teknik og Miljø - Planlægning og Byggeri Aarhus Kommune •Flemming Meyer •Master of Law, Special Consultant •Municipality of Aarhus •Department of employment.
Dagens program  Emne: Tim Berners-Lees WWW koncept og deraf følgende innovationer Forbered hver for sig Præsenter og diskutér i grupper Fremlæggelse med.
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
E/R model Enhanced E/R-model (EE/R-model) Relationelle model Relationelle algebra Omformning fra E/R-model til relationelle model Tirsdag.
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
Tekst starter uden punktopstilling For at få punkt- opstilling på teksten, brug forøg indrykning For at få venstre- stillet tekst uden punktopstilling,
Unit 1 English Summative Assessment, Poem
Arkitektur Embedded SQL Tema Persistens
Danish-Chinese Workshop on ”Land Questions” November 1st 2010 Aalborg University.
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
SQL - Database Lektion 3 7. Semester.
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
Arne Winther Et værdifuldt samarbejde mellem hospital og produktudvikler.
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
Indsæt nyt billede: Format: B 254 x 190,5 mm Efter indsættelse, højreklik på billedet og placér det bagerst. Delete det gamle foto Model-Driven Development.
View Procedures Trigger og Function Jesper Tørresø DAB1 E07 1. november 2007.
Self-Organizing Criticality. Definition of Innovation In an abstract, systems-theoretical approach, innovation can be understood as a critical event which.
Portfolio. Portfolio – what? Portfolio is used in more ways –Product or presentation –Process –Learning –Evaluation Often we distinguish between a learning.
Medialogy Learning Spaces in Copenhagen What do we want ? What can we do ? Possibilities and concerns.
Algoritmer og Datastrukturer 1 Greylisting Gerth Stølting Brodal.
Database Normalization without Mathmatics
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
Kulturstudier M, KA Art Worlds Hvem skaber kunsten?
”Men hvis aftalen mellem EU og USA kommer i stand, bliver sådan en handel billigere for de danske forbrugere, siger handelsminister Pia Olsen Dyhr. - Jeg.
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
CUSTOMER JOURNEYS 12/9.
Delprøve 1, december 2011.
Statistics Denmark DISCO Kenneth Christensen Labour Market responsibility: DISCO Birgitte Brondum Income and Registers responsibility: SOCIO DISCO = Danish.
Ændr 2. linje i overskriften til AU Passata Light 30 SEPTEMBER 2014 DEIC CONFERENCE 2014 PHD STUDENT MATTEO PILATI AARHUS UNIVERSITY DEPARTMENT OF CULTURE.
NOEA/IT FEN - Databaser/Sikkerhed 1 Lektion 10 Sikkerhed og integritet Områder Autorisationsmatrix Realisering i SQL.
1 Welcome! The search process:  How to handle the search process (strategies)  Transform your topic into search terms  Search techniques  how to use.
Overskrift 40/42 pkt, Maks 2 linjer Underoverskrift, 14/16 pkt For at vise hjælpelinjer: 1.Højreklik på slidet og vælg “Gitter og hjælpelinjer” 2.Kryds.
Linking international students and Danish businesses.
Agenda 1.Informationer 1.Excel i fb.m. projekt 2 2.Reserver tid til projekt 2 3.Øvelse: a / b = c 2.Opsamling fra sidst 3.Estimation (konfidensintervaller)
Side 1Copyright © 2007 JaKoFi. All rights reserved. DB2 Performance: Optimering af SQL læsninger mod DB2 med AllFusion Gen Jan Erik Jensen, JaKoFi.
22/092VE/E00/RB1 Introduktion til SQL Datalogi 2VE E00 DIKU Forelæsninger 22/9 og 29/9.
KLAR TIL NYE MULIGHEDER
2009NOEA/IT - Databaser/SQL1 Realisering af den relationelle model i SQL-baserede DBMS’er SQL er mere end forespørgsler - det omfatter bl.a. –DDL Data.
Nyt tværfagligt innovations tilvalgskursus på DTU Diplom Vil du bruge din faglighed i tværdisciplinært samarbejde med ingeniørstuderende fra andre retninger?
Reliable Architecture Ved Henrik Bærbak Christensen Reflective Architectures Emne: reflective architecture overview 11 december 2009.
Tekstslide i punktform Rubrik, helst 1 linje Brug ”Forøg/Formindsk indryk” for at få de forskellige niveauer frem Danish Standards  Signe Annette Boegh.
Overskrift her Navn på oplægsholder Navn på KU- enhed For at ændre ”Enhedens navn” og ”Sted og dato”: Klik i menulinjen, vælg ”Indsæt” > ”Sidehoved / Sidefod”.
AAALAC-akkreditering Afdeling for Eksperimentel Medicin.
SQL Jesper Tørresø DAB1 E oktober Punkter for i dag. SQL baggrund. Relationel algebra. Brug af VS2005.
2009NOEA/IT - Databaser/arkitektur1 Den relationelle model En teoretisk model for databaser Hviler på et sundt teoretisk grundlag Omfatter: Datastruktur.
Institut for Sprog, Kultur og Æstetik Engelsk, semester, Tekstanalyse og -historie Jens Kirk Session One: "An Introduction to the Analysis,
SQL Jesper Tørresø DAB1 E September Punkter for i dag. SQL baggrund. Relationel algebra. SQL koncept –Vises ved brug af VS2008.
Kjeld Svidt  Institut for Byggeri og Anlæg  Aalborg Universitet IT i Byggeriet Semester 6, kursusgang Databaser (1) Kjeld Svidt
OPERATIONEL ANALYSE AF WEBADFÆRD OAW – LEKTIONSGANG 11.
Database Some walk through. Database Design – Begreber 1 Database: En fælles samling af logiske relaterede data (informationer) DBMS (database management.
3. time Her beskæftiger vi os med John F. Sowas forklaring af erfaringsviden. John F. Sowa.
DB analyse og modellering Jesper Tørresø DAB1 F Februar 2008.
 Jens Bennedsen 2002Objektorienteret systemudvikling GRASP mønstre Basale ansvarsplaceringsregler.
Omsætning af en model til en RDB Jesper Tørresø DAB1 F Marts 2008.
Database Some walk through lv/ Figures & some text from: © Pearson Education Limited 1995,
DB analyse og modellering
Compositional Design Principles “SemiCiv”
Software Testing Software testing.
Description of career Geochemists study the amount and distribution of chemical elements in rocks and minerals Study elements in soil and water They help.
The Effects of Depressants on the Pulse Rate of Lumbriculus Variegatus
Impact and usage of the UI in Regulations No. [148]/[149]/[150]
Physics 4: Atomic Structure
MEIC Alternative Design Part II
Structure and Organization in Interpretation of Literature Essays
CS 3800 Switch/Router Lab Project Introduction
The Nested Splat! Series
A Constitutional Monarchy, Parliamentary Democracy, & Federation
Scientific Method – Steps 1-2
Præsentationens transcript:

Opsummering

Basic Definitions Database: A collection of related data. Data: Known facts that can be recorded and have an implicit meaning. E.g. “John B. Smith” a name123456789 a number ---two pieces of data If they are used in a query like “who is the head of the department and what is his ssn” the data will turn into information (give an implicit meaning) Mini-world: Some part of the real world about which data is stored in a database. For example, student grades and transcripts at a university.

Application programs/queries User/programmers Database System Application programs/queries DBMS Software Software to process queries/programs Software to access storede data Stored database Stored database definition Meta data

Main Characteristics of the Database Approach Self-describing nature of a database system: A DBMS catalog stores the description of the database. The description is called meta-data). This allows the DBMS software to work with different databases. Insulation between programs and data: Called program-data independence. Allows changing data storage structures and operations without having to change the DBMS access programs.

Additional Implications of Using the Database Approach Flexibility to change data structures: database structure may evolve as new requirements are defined. Availability of up-to-date information – very important for on-line transaction systems such as airline, hotel, car reservations.

Data Models Data Model: A set of concepts to describe the structure of a database, and certain constraints that the database should obey. Data Model Operations: Operations for specifying database retrievals and updates by referring to the concepts of the data model. Operations on the data model may include basic operations and user-defined operations.

Schemas versus Instances Database Schema: The description of a database. Includes descriptions of the database structure and the constraints that should hold on the database. Schema Diagram: A diagrammatic display of (some aspects of) a database schema (fig 2.1). Schema Construct: A component of the schema or an object within the schema, e.g., STUDENT, COURSE. Database Instance: The actual data stored in a database at a particular moment in time. Also called database state (or occurrence).

....... End users External view Data independence Conceptual Schema Internal Schema Conceptual Schema External view ....... End users Data independence Stored database

DBMS Languages Data Definition Language (DDL): Used by the DBA and database designers to specify the conceptual schema of a database. In many DBMSs, the DDL is also used to define internal and external schemas (views). In some DBMSs, separate storage definition language (SDL) and view definition language (VDL) are used to define internal and external schemas.

DBMS Languages Data Manipulation Language (DML): Used to specify database retrievals and updates. DML commands (data sublanguage) can be embedded in a general-purpose programming language (host language), such as Java or C# Alternatively, stand-alone DML commands can be applied directly (query language).

DBMS Languages High Level or Non-procedural Languages: e.g., SQL, are set-oriented and specify what data to retrieve than how to retrieve. Also called declarative languages. Low Level or Procedural Languages: record-at-a-time; they specify how to retrieve data and include constructs such as looping.

Conceptual Data Models AH/EDB FEN Databaser Conceptual Data Models 07-04-2017 A conceptual model of the data on which the IT systems of an organisation are based Independent of implementation Stable over time Conceptual data structure doesn't change as much as functionality Conceptual models are to be transformed to a database model as the relational model Databaser/Modellering

ER Model: Concepts Entities Relations Weak Entity Types Attributes AH/EDB FEN Databaser ER Model: Concepts 07-04-2017 Entities Attributes Atomic Composite Multi valued Attribute values Entity types Keys Domains Relations Cardinality ratio Participation (total / partial) Relations may have attributes Weak Entity Types Identifying owner Identifying relation Partial key A weak entity always has total participation in the identifying relation. Databaser/Modellering

ER Diagram for the Company Database AH/EDB FEN Databaser 07-04-2017 ER Diagram for the Company Database Databaser/Modellering

EE/R-diagram

Overlapping subclasses

Den relationelle model Den relationelle model er en datamodel med specielt sigte på relationsdatabaser Den relationelle model er en logisk datamodel, der beskriver hvordan data struktureres i relationsdatabaser

Den relationelle model Den relationelle model beskrives ved hjælp af en række veldefinerede begreber: domæner relationelle skemaer relationer attributter tupler primærnøgler, fremmednøgler begrænsninger (constraints)

Eksempel på tabeller som repræsentation af relationer

Nøglebegrebet En nøgle er en attributkombination, som entydigt identificerer en forekomst i en tabel. En nøgle er minimal, dvs.. fjernes een attribut, er den ikke længere entydig. Alle attributter fra tabellen vil tilsammen altid være en (evt.. ikke-minimal) nøgle, kaldet en supernøgle. Der kan være flere forskellige kandidatnøgler i en tabel Der vælges altid en primærnøgle fra mængden af kandidatnøgler

Tabelsammenhænge repræsenteres ved fremmednøgler en fremmednøgle er een eller flere attributter i en tabel, som svarer til primærnøglen i en anden tabel en fremmednøgle peger på en forekomst i en anden tabel og fortæller, at her ligger resten af oplysningerne fremmednøglen og primærnøgleattributterne i den tabel, der refereres til, skal have samme domæne.

Integritetsregler Integritet: at være sammenhængende Domæneregel: Værdien af en attribut skal være en atomisk værdi fra dom(A) Entitetsintegritet: En primærnøgle må ikke indeholde NULL-værdier Referenceintegritet: En fremmednøgle skal enten være NULL eller referere til en forekomst med en tilsvarende primærnøgleværdi Semantisk integritet: Forskellige regler, der i modsætning til de andre former for integritet, afhænger af den bestemte database.

DBMS-understøttelse DBMS’et bør understøtte: Domæneintegritet Entitetsintegritet Referenceintegritet Semantisk integritet Udbredte relationelle DBMS understøtter kun 1 og 4 i begrænset omfang.

Datamanipulation i den relationelle model - relationsalgebraen Arbejder på hele tabeller dvs. alle operationer tager tabeller som input og returnerer nye tabeller Hermed kan operationer sammensættes til udtryk (som almindelige regneudtryk) Operationer: rækkeudvælgelse (RESTRICT/SELECT) søjleudvælgelse (PROJECT) sammensætning af tabeller (JOIN) mængdeoperationer (UNION, INTERSECTION, MINUS, PRODUCT) avancerede operationer (OUTER (LEFT/RIGTH) JOIN) Det er det, man forstår ved en algebra!

Relational Algebra - Overview

Table Design Transformation from E/R-model to Relational Model Eigth Steps Algorithm Does not always yield an optimal design, but provides a good starting point for the final design of tables

Step 1: For each regular entity create a table For composite attributes only the components are included. Multi-value attributes are not included (they are considered in step 6). Choose a primary key. Step 2: For each weak entity type create a table All attributes from the weak entity are included. The primary key from the owner is included as foreign key. The primary key is composed by the owner’s primary key and the partial key. Step 3: For each (binary) 1:1-relation type include primary key of one participant as foreign key in the other Any attribute on the relation type is included with the key. If possible, include on a side with total participation.

Step 4: For each (binary) 1:n relation type include primary key of 1-side as foreign key on n-side Any attribute is included with the key on the n-side. Step 5: For each (binary) n:m relation type create table with participating entity types primary keys as foreign keys Any attribute on the relation is included in the new table. Primary key is composed of the foreign keys. This may also be applied to binary 1:1- and 1:n relations – in particularly if there are relatively few instants of the relation type. Step 6: For each multi value attribute create table with primary key of entity type as foreign key and the multi value attribute The primary key of the new table is composed of the foreign key and the multi value attribute.

Step 7: For each n-ary (n>2) relation type create a table with the primary keys of all participating entity types as foreign keys Any attribute on the relation type is included. The primary key is composed of the included foreign keys.

Step 8: B. Pull-down (only in case of disjoint, total specialisation): Create a table for each subclass Include (“pull down”) all attributes from the super class in each table Use the primary key from the super class as primary key in the new tables

Step 8: Create one table for the superclass C. Pull-up-1: (only in case of disjoint specialisation): Create one table for the superclass Include (pull up) all attributes from the subclasses Add a type attribute

Step 8: Create one table for the superclass D. Pull-up-2: (in case of overlapping specialisation): Create one table for the superclass Include (pull up) all attributes from the subclasses Add a type flag for each subclass

Informal Design Guidelines Table Semantics A table should hold information about one and only one entity/concept from the real world Don’t mix information about more things in one table Avoid Redundant Information Waste of storage Update Anomalies Minimise NULL-values Storage requirements Multiple interpretations (ambiguity) Disallowing the generation of spurious tuples when joining tables.

Normalisation Normal forms are the formal way to state design guidelines. Normalisation is the process. 6 normal forms (NF) are defined: 1st, 2nd, 3rd, and Boyce-Codd (BCNF). 4th and 5th NF BCNF is the one of most practical interest.

Guideline for Normalisation All attributes are to depend on the key, the whole key, and nothing but the key. So help me Codd.

SQL DDL create definition af table, view alter tilføje felter, ændre felter tilføje constraint drop grant / revoke DML insert update delete select

(id int IDENTITY(1,1) primary key, navn varchar(20)); /* automatik autoincrement pa primaer noeglen */ /* create table test (id int IDENTITY(1,1) primary key, navn varchar(20)); */

Comparing NULL’s to Values The logic of conditions in SQL is really 3-valued logic: TRUE, FALSE, UNKNOWN. When any value is compared with NULL, the truth value is UNKNOWN. But a query only produces a tuple in the answer if its truth value for the WHERE clause is TRUE (not FALSE or UNKNOWN).

Use is or is not select Fname, lname from employee where superssn is null Instead of = or != Since sql considers each null value as being distinct from every other null value

AGGREGATE FUNCTIONS Include COUNT, SUM, MAX, MIN, and AVG Query 15: Find the maximum salary, the minimum salary, and the average salary among all employees. Q15: SELECT MAX(SALARY), MIN(SALARY), AVG(SALARY) FROM EMPLOYEE Some SQL implementations may not allow more than one function in the SELECT-clause

GROUPING (cont.) Query 20: For each department, retrieve the department number, the number of employees in the department, and their average salary. Q20: SELECT DNO, COUNT (*), AVG (SALARY) FROM EMPLOYEE GROUP BY DNO In Q20, the EMPLOYEE tuples are divided into groups--each group having the same value for the grouping attribute DNO The COUNT and AVG functions are applied to each such group of tuples separately The SELECT-clause includes only the grouping attribute and the functions to be applied on each group of tuples A join condition can be used in conjunction with grouping

THE HAVING-CLAUSE Sometimes we want to retrieve the values of these functions for only those groups that satisfy certain conditions The HAVING-clause is used for specifying a selection condition on groups (rather than on individual tuples)

THE HAVING-CLAUSE (cont.) Query 22: For each project on which more than two employees work , retrieve the project number, project name, and the number of employees who work on that project. Q22: SELECT PNUMBER, PNAME, COUNT (*) FROM PROJECT, WORKS_ON WHERE PNUMBER=PNO GROUP BY PNUMBER, PNAME HAVING COUNT (*) > 2

Inner join select pnumber, dnum, fname, lname, address from ((project join department on dnum = dnumber) join Employee on mgrssn = ssn) where plocation = 'Stafford'

Outer join select fname, lname, dname as lederAf from (employee left join department on ssn = mgrssn) John Smith NULL FrankLin Wong Research Joyce English NULL Ramesh Narayalan NULL James Borg Headquarters Jennifer Wallace Administration Ahmad Jabbar NULL Alicia Zelaya NULL

Select select < attribute and function list> from < tablelist> [where < condition>] [group by <grouping attributelist>] [Having <group condition>] [Order by < attributelist>]

SQL Views: An Example CREATE view ViewWorksOn(fname, lname, pname, hours) AS (SELECT FNAME, LNAME, PNAME, HOURS FROM EMPLOYEE, PROJECT, WORKS_ON WHERE SSN=ESSN AND PNO=PNUMBER GROUP BY fname, lname, PNAME,hours)