Opleiding AI cursus Databases

Presentatie over: "Opleiding AI cursus Databases"— Transcript van de presentatie:

1 Opleiding AI cursus Databases
Eerste college Donderdag 5 februari 2004 Drs. F. de Vries Presentielijst

2 Programma vandaag Opzet cursus Studiebelasting
Website: rooster, literatuur Stof: bespreking hoofdstuk 1 en 2

3 Introductie Zelfde, kleine cursus als vorige jaren Omvang:
goede evaluatie Omvang: eerst: 2 oude studiepunten, 2 * 1.43 = 2,86, nu: 3 ECTS Practicumgroepen Studiegids: andere docent Problemen: grote aantallen studenten bij deze cursus Geen begeleiding op dinsdag Groepen om-en-om Indeling werkgroepen practicum: eerste 16 studenten: de even weken, 2e 16 studenten: de oneven weken

4 Cursusinhoud Het ontwerpen en modelleren van databases; structuur, integriteit en manipulatie van relationele databases; het E/R model; normalisatie van gegevens; Structured Query language (SQL); object-georiënteerde databases; gedistribueerde databases; databasemanagement. Eindtermen Kennisverwerving van de elementaire begrippen van moderne databasesystemen met betrekking tot ontwerp, structuur en manipulatie. Het verwerven van basisvaardigheid SQL. Inhoud Het ontwerpen en modelleren van databases; structuur, integriteit en manipulatie van relationele databases; het E/R model; normalisatie van gegevens; Structured Query language (SQL); object-georiënteerde databases; gedistribueerde databases; databasemanagement. UML toevoeging

5 Studiebelasting Tentamen boek 200 p = 40 uur
Extra stof UML 50 pag = 10 uur Colleges 4 x 2 = 8 uur Practicum 4 x 3 = 12 uur Voorbereiding = 14 uur Totaal 3 ECTS x 28 = 84 uur 3 opdrachten UML stof moet nog bekend gemaakt worden

6 Hoofdstuk 1

7 Inhoud hoofdstuk 1 In dit hoofdstuk de basisconcepten van databases
Na dit hoofdstuk kun je 4 vragen beantwoorden: Wat zijn de voordelen van een db Wat zijn de belangrijkste componenten Wat is data independence Welke soorten db systemen zijn er

8 1.1 Wat is een database? elk computer gebaseerd informatiesysteem,
met gegevens die gedeeld kunnen worden, door een variatie van applicaties Expliciet genoemd: het delen van de data door een grote variatie programma’s en niet 1 speciaal programma Wat valt er niet onder? - Een ouderwetse kaartenbak, want die zit niet in de computer Vraag: is een digitaal adressenboek een database? Kan dit gedeeld worden? Vraag: is Excel een bestand database? Nee, want Excel is 1 speciaal programma Ja, je kunt met VB een programma maken? Vraag: is een Access bestand een database? Ja, gegevens kunnen gedeel worden, meerdere applicaties mogelijk

9 1.2 Database systemen versus bestandsverwerkingssystemen
Wat is een bestand (file)? Voorbeeld: bedrijf, elke afdeling een eigen bestand? Voorbeeld fig. 1.1: delen van data en ‘redundancy’ Wat is een bestand? allerlei variaties: bestand is sequentieel of random access bestaat uit records en records bestaan uit velden met index of met pointers Voorbeelden: voorraad, personeel, klanten, boeken, etc. Traditioneel: 1 bestand met 1 applicatie [ Wanneer wordt een bestand een database? ] Database: bestandsintegratie, gedeelde data, meerdere applicaties

10 Voorbeeld: Drie systemen met drie afzonderlijke bestanden die elkaar overlappen = redundancy Bestand 1 = voorraadcontrole nivo, re-order-level = opnieuw bestellen? Plus: voorraadnummer (voorraad) = itemnummer (bestelling) beschrijving, eenheid/item kosten Bestand 2 = orderverwerking 3 attributen gedeeld met voorraadcontrole 6 attributen gedeeld met betalingsverwerking Bestand 3 = betalingsverwerking klantnaam, adres, rekening nummer bedrag, order kosten, krediet limiet Plus betaling ontvangen

11 1.2 vervolg Gevaren van “redundancy’? Oplossing: data-integratie
Ambiguïteit Inconsistentie Verspilling: tijd, inspanning, geld Oplossing: data-integratie Minimaliseren van ‘redundancy’ Gespecialiseerde software nodig Functionele abstractie gevaren Voorbeeld: voorraadnummer gelijk aan itemnummer? Voorbeeld: Waarden inconsistentie: prijveranderen moet in twee bestanden gebeuren, zo niet: inconsistentie datatype inconsistentie: voorraadnummer en itemnummer moeten hetzelfde type zijn als ze hetzelfde representeren Data moeten dubbel ingetikt en bijgehouden worden op de gedeelde items Ideaal: elke gegeven slechts 1 keer bijhouden, minimaliseren van redundancy Kan niet helemaal uitgebannen worden (waarom niet?) Data-integratie gaat samen met software abstractie! Waarom? - de basisoperaties zijn voor elke toepassing hetzelfde: inkijken, toevoegen, weglaten, veranderen

12 1.3 Componenten DBMS is software met taken:
Inkijken, toevoegen, weglaten, veranderen Voordelen database systeem: Zelfde data op diverse manieren te gebruiken Gebruik ligt niet van tevoren vast Applicaties worden eenvoudiger Over alle applicaties heen is er een taakabstractie voor de basistaken van elke applicatie in het DBMS Gebruikers en applicatie hoeven niet te weten HOE de data zijn georganiseerd, dat is abstractie Organisatie kan zelfs in files zijn Dat levert grote voordelen op Nadelen? Binding aan DBMS organisatie

13 Meerdere gebruikers per applicatie
Meerdere applicaties per database 1 database management systeem Data integratie DBMS moet intern gelaagd zijn om als ‘bemiddelaar’ of interface tussen gebruikers en data te kunnen opereren Logisch schema naar de applicaties toe Fysiek schema naar de data toe

14 Functionaliteit DBMS Delen en integreren van data
Ondersteunen van meerdere views Controleren van gelijktijdige toegang Veiligheid en integriteit ondersteunen Ad 1. Is al besproken Ad 2. VIEWS Meerdere views mogelijk op dezelfde data Ad 3. CONCURRENCY Zelfde data eventueel gelijktijdig gebruiken [ locks: read locks write locks] Ad 4. SECURITY Ongewenste toegang voorkomen Herstel bij systeemstoring Ad 4. INTEGRITY Zelfde data in zelfde format Complexe integriteitscontroles in DBMS Onderwerp komt later terug

15 1.3 vervolg Componenten van een db systeem: Ook in ‘lagen’ te zien
Gebruikers Applicaties Het DBMS De data Het ’host’ systeem Ook in ‘lagen’ te zien

16 Samengeklapte views Samengeklapte applicaties Let op: host tussen dbsm en data in, host systeem kan ook gepasseerd worden door het DBMS ivm efficiency Gelaagdheid Extern Conceptueel Intern

17 1.4 - DBMS gelaagdheid

18 1.4 - DBMS gelaagdheid (1) Centraal: het conceptuele nivo
Logische beschrijving van data Complete beschrijving van alle data-objecten Data-objecten= file, record, veld, set velden Repository voor beschrijving: DD Logisch = beschrijving en samenhang, onafhankelijk van de fysieke opslag [ UML = analyse nivo ] Item = record, veld, bestand, set, Conceptueel schema = beschrijving van alle objecten tbv de datadictionary Laagste nivo dat beschikbaar is voor de gebruiker Gebruiker wordt bewust afgesloten van de fysieke opslag View

19 1.4 - DBMS gelaagdheid (2) Data Dictionary Alle db objecten opgenomen
Elk db object heeft slechts 1 ingang DD is database op zich Dit is het Conceptuele schema Mappings naar de views Mapping naar hostsysteem Logisch = beschrijving en samenhang, onafhankelijk van de fysieke opslag [ UML = analyse nivo ] Item = record, veld, bestand, set, Conceptueel schema = beschrijving van alle objecten tbv de datadictionary Laagste nivo dat beschikbaar is voor de gebruiker Gebruiker wordt bewust afgesloten van de fysieke opslag View

20 Dit is het 3-lagen model van ANSI/SPARC 1978
Mappings tussen de drie lagen Ideaal is de scheiding van de drie lagen In de praktijk wordt dit ideaal zelden precies bereikt Jhet komt zelfs voor dat het DBMS het OS passeert en zelf de fysieke opslag beheert, ivm performance

21 1.4 - DBMS gelaagdheid (3) Logical data-independence
Het afschermen van gebruikers en applicaties voor wijzigingen in conceptuele schema Physical data-independence Het afschermen van gebruikers en applicaties voor wijzigingen in de fysieke opslag Wijzigingen in het conceptuele schema werken door in alle views Logical data-independence = gebruiker of applicatie merkt niets van veranderingen in het conceptuele schema omdat de views zijn aangepast om dat te voorkomen Die onafhankelijkheid is een mooi streven [ talloze voorbeelden te bedenken waar het niet lukt dit te bereiken ] [ Voorbeeld waar het wel lukt: de precisie van een item neemt toe in het conceptuele schema, bv ipv 2 cijfers worden er 3 cijfers achter de komma gegeven, in de mapping naar de view kan dit ongedaan gemaakt worden, zodat het oude programma niets merkt ] Voorbeeld: - toevoegen van een data-item: hoeven de applicaties niet van te merken - weglaten van een data-item: - veranderen van een data-item

22 1.5 Typen databases 1. hiërarchie 2. netwerk 3. relationeel
4. object-georiënteerd Diverse vormen van conceptuele data organisatie Uitgereidere behandeling 1 en 2: zie hoofdstuk 6 - van historisch belang, maar nog steeds gebruikt 3: zie hfst 3,4,5 - de standaard, wordt overal gebruikt, maar met nadelen 4: zie hfst 7 - in ontwikkeling, maar nog weinig commercieel in gebruik [ Milestones 1968 IMS van IBM 1975 codasyl rapport 1970 artikel Codd 1981 smalltalk van Xerox parc ]

23 1.5.1: hiërarchische db Kenmerken Record-sets op elk nivo
Meerdere pointers naar lager nivo Meerdere nivo’s mogelijk Bv: Topnivo: een set van klanten records elke klant heeft een set orders, elke order heeft een set items Geen terugverwijzing mogelijk 1968 IBM komt met IMS = Information Management System In de mainframe tijd [ vgl oprichting van SARA in 1971, voor rekenen op de universiteit, Geen db aanwezig, Mainframe een Cyber, met NOS/BE als os ] Geen terugverwijzing mogelijk: - een item weet niet in welke order hij zit - een order weet niet bij welke klant hij hoort Logische en fysieke ordening komen overeen?? [ hangt van de datastructuur af denk ik: op tape anders dan sequentieel ]

24 Nadelen: - redundancy, dupliceren van data nodig - bv de prijs van nuts komt 3 x voor - bv de prijs van nails komt 3 x voor Nog een nadeel: - geen onformatie van dingen die niet besteld zijn Samenvatting ndelen: te veel data (duplikatie) en te weinig data (missing data) Oplossing: apart bestand aanleggen met cross-links

25 1.5.2: netwerk db Kenmerken Netwerk bestaat uit records en links
Link is een fysieke pointer naar sets ‘ownership’ wordt daarmee vastgelegd Bv Klant is ‘owner’ van Orders Voordelen: link is niet hiërarchisch vermindering van ‘redundancy’ Codasyl Database taskgroup opgericht in 1970 Doel: standaard definitie maken voor netwerken Definitief rapport in 1975: het Codasyl rapport, standaard voor netwerk gebaseerde databases [ hebben ze 5 jaar over gedaan!! ] Codasyl model = netwerk model

26 Voordeel: meer flexibiliteit door pointers, items kunnen in verschillende sets van verschillende owners zitten. Een record kan vele owners hebben: - order is owner van een set van hoeveelheden - item is ook owner van een set van hoeveelheden, maar een andere set [ Kan ook een nadeel zijn: welke owner mag de set wijzigen? ] Nadeel - veel pointers, wie behoud het overzicht [ vgl chasing wild pointers ] - queries worden lastiger, zie hfst 6 later

27 1.5.3: relationele db Kenmerken: Begrippen:
Alle data in tabellen met sleutels, geen harde pointers Query taal gebaseerd op relationele algebra Begrippen: Relatie = 2 dimensionele tabel Rij = tuple (vlg record) Kolom = attribuut Gebaseerd op het werk van EF Codd, beroemde ACM artikel uit 1970: “A relational Model of data for Large Shared Databanks” [ nb een eenling die het hele Codasyl team verslaat ] Rond 1980 algemeen geaccepteerd als het beste model voor DBMS ontwikkeling Randvoorwaarden: - elke tuple in een tabel moet uniek zijn, sleutel zorgt daar voor Voordeel relationele systeem: - geen fysieke pointers meer - wel logische of semantische pointers - meer gebruiksgemak Nadelen: - statische gegevens

28 Hoe zoek je een order voor een rekening bij elkaar?
- door orders en orderregel te vermenigvuldigen - en op een ordernummer te selecteren, bv O1 - je krijgt dan een tabel met twee tuples met stocknr S1 en S2 - deze vermenigvuldig je met de tabel stock, - je krijgt dan een invulling van s1 en s2 Je kunt in deze tabel een nieuwe kolom maken met bedrag = sprice * hoeveelheid Je kunt de bedragen optellen

29 1.5.4: object-georiënteerde db
Kenmerken Klasse is definitie van instanties w.b. structuur en gedrag Structuur = attributen, eigenschappen, variabelen, data structuur Gedrag = operaties, methoden Klassen gebruiken andere klassen

30 OO klassen - attributen
Klasse Klant Klantnummer, naam, stad, Klasse Order Ordernummer, klantnummer Klasse Voorraad Voorraadnummer, itemnaam, prijs Klasse OrderRegel? Ordernummer, voorraadnr, hoeveelheid

31 OO klassen - operaties Klasse Klant Klasse Order Klasse Voorraad
Klasse OrderRegel Operaties (welke klasse?): Maak een pakbon Stuur rekening naar klant Semantiek zit in de operaties van de klassen Welke klasse maakt/stuurt een rekening? een print object? - dan zijn er van alle 4 de genoemde klassen gegevens nodig een operatie in Order? - dan zijn er van 3 klassen gegevens nodig

32 Voordelen OO Nog meer gebruikers-georiënteerd
Afscherming van onderliggende data-structuur en relaties Afscherming wordt onderdeel van database ipv de applicatie Afscherming doordat objecten andere objecten aanroepen en de gebruiker dit niet hoeft te weten = delegatie Nadelen OO databases = nog geen preciese definitie, zoals wel bij relationele model

33 Hoofdstuk 2

34 Inhoud hoofdstuk 2 Welke stappen in het ontwerproces?
Welke concepten waarmee je formeel de semantiek kunt vastleggen Welke modellen om die semantiek mee uit te drukken?

35 2.1 het ontwerpproces 1. Vereisten  conceptueel model
2. Conceptueel model  conceptueel schema 3. Conceptueel schema  fysiek schema Fase 1: requirements (WAT) komen van de stakeholders, opdrachtgevers het conceptuele model is database onafhankelijk het is een semantisch model [ HOE - analyse nivo van UML-UP] Fase 2: het conceptuele schema is voor de applikaties en de gebruikers het laagste nivo - het conceptuele schema is database specifiek een database kan op diverse machines draaien Bv een relationeel systeem Fase 3: het fysieke schema is voor de DBA - het fysieke schema is machine specifiek

36 2.2 concepten semantisch modelleren (1)
1. Assertion Beweringen mbt eigenschappen van een type object Beweringen evt verwerpen Bereik van beweringen vastleggen Database semantiek is geformaliseerd itt semantiek van natuurlijke taal Database semantiek heeft beperkte complexiteit en is goed te begrijpen Natuurlijke taal is lastig, ongeformaliseerd, complex 7 concepten, nummer 1 = Assertion (bewering) Type object = lichaam, attributen of eigenschappen: lichaam heeft hoofd, handen, voeten, etc Bewering: lichaam heeft groot hoofd is ok Bewering verwerpen: Bewering lichaam heeft kruiwagen is niet ok, want kruiwagen is geen eigenschap Bereik van beweringen: alleen over de vastgestelde eigenschappen kan iets gezegd worden Met type object en eigenschappen wordt een beperkt deel van de wereld vastgelegd

37 2.2 concepten semantisch modelleren (2)
2. Convertibility Bewering = subject + predikaat Regel: er is een 1-op-1 relatie tussen subject en predikaat Evt extra eigenschap invoeren Concept nummer 2 = Convertibility (omkeerbaarheid?) Assertie = Subject plus predikaat Subject = kees Predikaat = groot hoofd en kleine romp Predikaat kan bij meerdere subjecten Kees passen, maar volgens de regel mag dat niet Regel: Alle asserties zijn uniek Extra eigenschap invoeren om assertie uniek te maken, bv Kees + paspoortnummer

38 2.2 concepten semantisch modelleren (3)
3. Relatability Voorbeeld: type Boeking = klant, vakantie, vertrek type Vakantie = nummer, plaats, prijs, datum Regel verbindbaarheid: de waarde van een eigenschap kan aan slechts 1 instantie van een bijbehorend type verbonden worden Concept nummer 3 = relatability Type naam = lijst met eigenschappen Type Boeking = klant, vakantie,betaald Type Vakantie = nummer, plaats, prijs, vertrekdatum Regel de waarde van een eigenschap kan aan 1 en slechts aan 1 type refereren Vakantie bij boeking kan slechts aan 1 instantie van vakantietype gekoppeld worden

39 2.2 concepten semantisch modelleren (4)
4. Object relativity Vakantie: zowel type als eigenschap? Regel: type en eigenschap zijn alleen maar verschillende interpretaties van hetzelfde object Ondersteund door: Generalisatie/specialisatie Aggregatie Grouping Concept nummer 2 = Convertibility (omkeerbaarheid?) Assertie = Subject plus predikaat Subject = kees Predikaat = groot hoofd en kleine romp Predikaat kan bij meerdere subjecten Kees passen, maar volgens de regel mag dat niet Regel: Alle asserties zijn uniek

40 2.2 concepten semantisch modelleren (5)
Generalisatie – specialisatie Subtype definitie met IS-A-type Type Werknemer = nr, afd, startdat. Type Secretaresse = IS-A-Werknemer, .. Aggregatie Toevoegen aan onderdeel: IS-PART-OF Grouping TYPE-OF relatie Generalisatie – specialisatie eigenschappen naar boven toe factoriseren = generaliseren Bv secretaresse en programmeur hebben als werknemer eigenschappen gemeen Aggregatie Een type kan bestaan uit andere typen, zoals bij vakantie Als het om onderdelen van een geheel gaat kunnen de onderdelen worden voorzien van de eigenschap IS-PART-OF-type Grouping Als je wilt groeperen dan geef je dit aan met een TYPE-OF relatie [ verschil met aggregatie?]

41 Als je zegt dat een motor een onderdeel is van een auto, dan ken je een motor toe aan een specifieke auto Een set van motoren kan hetzelfde basisontwerp hebben, dit kan je met een TYPE-OF associatie aangeven Type motor-type = vermogen, aantal cylinders, opbouw, motorblok? (camshaft) Type motor = motornummer, fabriek, datum, TYPE-OF-motor-type, IS-PART-OF-auto PART-OF relatie is 1-op-1 TYPE-OF realtie is veel-op-1 Een bepaald motor-type kan bij vele motoren passen, maar elke motor heeft maar 1 motor-type

42 2.3 Database modelleren Gegeven: een voorbeeld met 7 vereisten
Uitwerking in 3 conceptuele modelvormen E/R model Functioneel data model Semantisch objecten model Eerst de requirements Dan het omzetten daarvan in de drie modelvormen

43 Voorbeeld vereisten Rock Solid banking Corporation heeft de volgende vereisten opgesteld: Elke rekening bij de bank heeft: klantgegevens (referentienr, naam, adres, status), een rekeningnummer, bedrag (balance) 2. Er zijn 2 soorten rekeningen: spaarrekening (deposit) en betaalrekening (current) 3. Klanten mogen meerdere rekeningen hebben 4. Een rekeningnummer is uniek 5. Rekeningen kunnen door klanten gedeeld worden 6. Elke klant heeft een uniek referentienummer 7. Elke rekening hoort bij 1 afdeling van de bank 8. Afdelingsgegevens van de bank (naam, adres, manager) 9. De naam van de bankafdeling is uniek

44 1. Het E/R model (1) Entiteiten-Relatie model van Peter Chen (1976) (Ook wel EAR = entiteiten – attributen – relaties) Meest bekende model van de drie Entiteit = “items in the real world that are capable of a unique existence” [ je kunt ook zeggen: een abstractie, waarvan instanties te maken zijn..] Voorbeeld: bank, Klant, Rekening Afbeelding: box met naam ENTITEIT in hoofdletters Attribuut = eigenschappen van de entiteit Afbeelding: ovaal met naam met hoofdletter Onderstreping: sleutel Evt gecombineerde sleutel mogelijk Relatie = benoemde verbinding tussen entiteiten

45 1. Het E/R model (2) Relatie Benoemde verbinding tussen entiteiten
[naam leest 1 kant op: bank behandelt rekeningen, maar niet: rekening behandelt bank, zie volgende sheet?!? ..] Cardinaliteit: 1-op-m, wel twee kanten op lezen Bank behandelt meerdere accounts – een account hoort bij slechts 1 bank

46 1. Het E/R model (3) Cardinaliteit: m-op-n, twee kanten op lezen:
1- een klant kan meerdere rekeningen hebben 2- een rekening kan door meerdere klanten gedeeld worden [ Let op: Dit leest niet goed: account-handles-bank Een rekening wordt behandeld door een bank < is handled by> zou mooier zijn ] Cardinaliteit: 1-op-1: voorbeeld [ niet op de sheet] Een bankafdeling heeft 1 manager, en elke manager behoort bij 1 en slechts 1 bankafdeling

47 1. Het E/R model (4) Relaties die zelf entiteit kunnen worden: [ vgl associatieklasse bij UML] Voor elke rekening van elke klant wordt een registratie vastgelegd, deze is uniek voor de combinatie klant-rekening Deze kan zelf eigenschappen hebben: datum Dit is een zwakke entiteit, omdat deze alleen bestaat bij de gratie van een rekening en een klant Let op: de cardinaliteit wordt opgesplitst in 2 keer 1-op-m Afbeelding: dubbele box

48 1. Het E/R model (5) Probleem bij ER model: item kan entiteit en attribuut tegelijk zijn, bijvoorbeeld de manager is zowel werknemer als attribuut van de bank Oplossing: recursieve relatie

49 x Recursieve relatie: Supervisie relatie: Elke werknemer heeft supervisie = een baas Managed-by relatie: bank-werknemer 1-op-1 manager Wat is er nog niet uitgedrukt: de manager van een set werknemers = de manager van de bank Dit wordt opgelost met Enhanced ER model, Dmv subtyping en verfijningen ervan

50 E-E/R model: subtyping
Subtyping: specialisatie en generalisatie van entiteiten

51 x Wordt hier gebruikt: specialiseren van werknemers EMPLOYEE
in gewone = EMP en speciale = MANAGER [ let ook weer op de leesrichting: niet: bank-employed at- employee, maar andersom] Opgelost: nu is de manager ook degene met de supervisie Let ook op de ternary (drie-heid) relation

52 x Wat wordt hier teogevoegd: Subset symbool = de lijn met halve cirkel
D = disjoint set, je hoort bij het een of het ander, niet beide O = inclusive or set (either or both) Must be lijnene geven aan dat er een entiteit aanwezig moet zijn Waarom must-be-lijnen niet bij employee? Er kunnen werknemers voorkomen die niet in de drie aanwezig groepen vallen: bv schoonmaker

53 E-E/R model: overerving
Meervoudige overerving, de clerical-manager heeft eigenschappen van beide

54 Aggregatie wordt met 1-op-1 relaties aangegeven
PART-OF relaties aan de linkerkant TYPE-OF relaties aan de rechterkant: een motor heeft slechts 1 ontwerp, maar met dat ontwerp kunnen meerdere motoren gemaakt worden

55 2. Het functionele datamodel
Kenmerken: Entiteiten en relaties door functies weergeven: Functie (argument) - - > > resultaat Diagram: lijkt op E/R diagram, maar net even anders Let op de enkele en dubbele pijlen Beschrijving db met functie declaraties Auteur is Shipman (1981) Relaties worden met wiskundige formules weergegeven: Functie(argument) -> functiewaarde Enkele pijlen = funktie waarde Dubbele pijl = multi-valued function: meerdere resultaten mogelijk

56 x Enkele pijlen = funktie waarde
Dubbele pijl = multi-valued function: meerdere resultaten mogelijk Diagram is niet volledig Let op: CUSTOMER HAS ACCOUNT, met dubbele pijl Maar ook: ACCOUNT ‘BELONGS TO’ CUSTOMER: met dubbele pijl

57 Beschrijving FDM (1) 1. CUSTOMER() - - - > > ENTITY
2. NAME(CUSTOMER) - - > STRING 3. HAS(CUSTOMER) - - > > ACCOUNT 4. CUSTOMER(ACCOUNT) - - > > INVERSE OF HAS (CUSTOMER) 5. REG_DATE (ACCOUNT, CUSTOMER) - - > String Een database wordt beschreven met een serie functie declaraties Wat levert uitvoering van een functie op? (let op dubbele pijl = set als resultaat) Lever een entity set op als resultaat Levert eigenschap op in de vorm van een string Levert alle rekeningen van een klant op Probleem met FDM’s is het delcareren in 1 richting: bv van klant naar rekening, maar niet omgekeerd Als je de set klanten van een rekening wilt hebben moet je de inverse nemen 4. Levert alle klanten op van een rekening In plaats van weak enitities kun je een multifuctioned argument invoeren 5. Levert de registratiedatum op

58 Beschrijving FDM (2) Ook functiebeschrijvingen voor: IS-A relaties
Aggregatie types Groeperingen Constraints: DEFINE CONSTRAINT MANAGES_BRANCH(BRANCH) - - > BELONGS_TO(MANAGER(BRANCH)) = BRANCH Voorbeelden: IS-A-EMPLOYEE(TECHNICIAN) - - > EMPLOYEE ENGINE(CAR) - - > ENGINE TYPES-OF-CAR(CAR) - - > > PRODUCES-CAR DEFINE CONSTRAINT MANAGES_BRANCH(BRANCH) - - > BELONGS_TO(MANAGER(BRANCH)) = BRANCH [ voordeel: functionele declaraties kunnen machinaal verwerkt worden, Nadeel: De vraag is of lijsten met functionele declaraties nog wel overzichtelijk zijn voor de gebruiker, ]

59 3. Het semantische object model
Kenmerken: De database wordt gerepresenteerd als een serie semantisch objecten Verschil met E/R model: relatie is ook attribuut Auteur is: Kroenke (1988) Vergelijking met ER model: Entiteit = semantisch object Attribuut = attribuut Relatie = ook een attribuut Visuele representatie zonder links

60 Semantic objects (1) Opmerkingen: elk object heeft een sleutel ID
De twee getallen geven een cardinaliteit met minimum en maximum aan Adres heeft attributen Attributen moeten wederkerig opgenomen worden: Klant heeft relatie met account, daarom moet klant ook weer terugkomen bij account Een cardinaliteit van 1,N betekent: een klant heeft 1 of meer accounts Een cardinaliteit van 0,N betekent: een afdeling beheert 0 of meer accounts

61 Semantic objects (2) Opmerkingen:
- hier vinden we het associatie object Registratie als apart object en vervolgens zowel bij Klant als bij Rekening

62 Semantic objects (3) Opmerkingen figuur 2.16
subtyping door middel van 0,ST: manager is een subtype van EMP Supertyping door middel van P: de parent van manager is EMP Opmerkingen figuur 2.17 voorbeeld van disjoint subtyping een drie-weg cardinaliteit: 0,1,1 betekent: een werknemer hoeft niet een van beide functies te hebben, maar als die fucntie wel wordt bekleed is het een van beide [ wordt er niet echt duidelijker op visueel ]

63 (4) Opmerkingen figuur 2.18 - aggregatie objecten zijn eenvoudig: een 1,1 cardinaliteit voor opgenomen objecten slot Opmerkingen figuur 2.19 Grouping: Een object ENGINE moet geassocieerd worden met een ENGINE_TYPE Het object ENGINE_TYPE kan met 0 of meer motoren geassocieerd worden

64 afronding Alle modelvormen hebben hetzelfde probleem: omzetten van vereisten in een leesbaar conceptueel model, dat voldoende uitdrukkingskracht heeft Eenvoudige modellen zijn goed weer te geven, hoe werken de modellen bij meer complexiteit?

65 Einde college 1 Volgende college op 12 februari