|
|
Created by Jenny Degling
almost 12 years ago
|
|
| Question | Answer |
| Databas | Är en organiserad samling av data |
| Data | Värden av kvalitativa eller kvantitativa variabler, som hör till ett set av saker. Vanligtvis resultatet av mätningar och visualiseras genom grafer eller bilder |
| Data, information, kunskap | Skillnaden är graden av abstraktion. Data är lägsta abstraktionen, sedan kommer information och sist kunskap |
| Strukturerad data | Data som finns i ett bestämt fält inom ett register eller fil. Exempel: data som finns i en relationell databas eller kalkylblad. |
| Data modell | En modell av de typer av data som kommer dokumenteras och hur data kommer lagras, bearbetas och nås. |
| Ostrukturerad data | Alla saker som inte kan klassificeras eller passas in i ett fält. Exempel: foton, bilder, filmer, hemsidor, e-mail, bloggar. |
| SQL | Structured Query Language. Ett programmeringsspråk som skapades för att hantera och göra data-förfrågningar i relationella database management systems |
| Semi-strukturerad data | En typ av strukturerad data men saknar den strikta datamodell strukturen. Tags eller andra markeringar används istället för att identifiera element (xml) |
| DBMS | Relational Database Management Systems. Består av en konceptuell fas, en logisk fas och en fysisk fas då man implementerar. |
| Lager (inom DBMS) | många databaser har mjukvara som når databasen på uppdrag av slutanvändarna. DBMS gränssnittet visas inte direkt. Specialisterna och administratörerna använder dock ett annat gränssnitt för att utveckla databasen - finns alltså olika lager inom mjukvaran beroende på vem som använder den. |
| Entity-Relationship modelling | Ett av sätten att ta sig an databasdesignen, man börjar med att identifiera viktig data och förhållandet mellan data som måste representeras i modellen. ”Top down” |
| Entitet | Representerar ett set av objekt som delar samma egenskap/er. Egenskaperna kallas för attribut |
| Attribut | Entitetens egenskaper |
| Enkla attribut | Attribut som inte kan delas upp mer. Exempel: telefonnummer |
| Sammansatta (composite) attribut | Attribut som kan delas upp mer. Exempel: namn kan delas upp i för- och efternamn |
| Single-valued attributes | Attribut som enbart håller ett värde. Majoriteten av alla attribut. Exempel: varje DVD-entitet har ett enkelt värde för catalogNo. |
| Multi-valued attributes | Attribut kan ha flera värden. Exempel: lektion 1 upg 4, att musiker kan spela flera instrument. Instrument är då ett flervärdesattribut och skrivs in i modellen med ett specificerat antal värden det kan anta [1..*] Får en egen tabell i schemat - Musiker_instrument(pnr*, instrument*) |
| Härstammande (derived) attribut | Attribut härstammar från värden av ett relaterat attribut. Ålder härstammar från födelsedatum, skrivs med / framför. DOB: 11/5/1992 /Age: 21 |
| Stark entitet | Är inte beroende av en annan entitet för dess primary key |
| Svag entitet | Är helt eller delvis beroende av en annan entitets existens för dess primary key |
| Multiplicity | Begränsar antalet gånger en instans av en entitet kan relatera till en instans i en annan entitet genom ett särskilt förhållande. Görs genom att gå igenom kravspec. eller liknande. Består av kardinalitet och modalitet. |
| Cardinality | visar max hur många gånger en instans av en entitet kan bli associerad med en instans av den relaterade entiteten |
| Modality | visar minst hur många gånger en instans av en entitet kan bli associerad med en instans av den relaterade entiteten. |
| Logiska designfasen | Översätter ER-modellen till ett set av relationella tabeller. Sedan försäkrar man att det inte finns någon överflödighet genom normalisation för att sedan kolla så att de kan utföra det som kunden vill att de ska kunna utföra samt kollar integritet begränsningar |
| relationell tabell | en tabell är ett set av värden som organiseras genom en modell som består av vertikala kolumner och horisontella rader |
| Förhållande i tabeller | Representeras genom primary/foreign key. Identifierar först barn- och förälderentiteten för att veta hur nyckeln ska placeras. |
| Specialization | Ett tillvägagångssätt för att definierar set av superklasser och deras subklasser. Set av subklasser definieras utifrån superklassen genom att plocka ut de attribut som är specifika för subklassen. Man identifierar också förhållandet mellan subklasser och andra entiteter eller subklasser → försöker maximera skillnaderna i en entitet för att urskilja olikheterna. |
| Generalization | Ett tillvägagångssätt där man identifierar en generell superklass från de ursprungliga subklasserna. Man försöker hitta likheter mellan entiteter för att hitta en potentiell gemensam superklass. |
| Paricipation constraint | Kan antingen vara mandatory eller optional. Detta placeras utan på strecket mellan superklassen och subklassen. Mandatory: varje fordon måste vara en van, buss eller bil. Optional: frivilligt |
| Disjoint constraint | Beskriver förhållandet mellan medlemmar av subklassen och visar om en superklass kan vara medlem i en subklass (OR) eller i flera (AND). |
| Entiteter i tabeller | För varje entitet skapas en tabell som innehåller entitetens enkla attribut. För sammanslagna attribut: inkludera enbart de enkla attribut som utgör de sammanslagna. |
| NORMALISATION | Ett mål är att gruppera kolumner till tabeller för att minimera upprepningar och där med minska fillagringen. |
| Insertion Anomalies | För att skriva in nya uppgifter så behöver man även lägga till ytterligare information om något som inte är relaterat i grund och botten – om man sedan då råkar skriva fel information på något av dessa ställen blir det en insertion anomali. För att skriva in information om något som kanske inte har någon personal än krävs null-värden (ej tillåtet att ha null-värden i PK!) |
| Deletion Anomalies | Om man tar bort en anställd som försvinner även information om arbetsplatsen, data som går helt förlorad om det var den enda anställda. |
| Modification Anomllies | För att ändra ett värde på adressen på arbetsplats måste adressen ändras på alla anställda som har den arbetsplatsen. Om det då blir fel information på något ställe i tabellen blir det en modification anomali. |
| decoupling | Separera informationen. Varje tabell ska bara vara ansvarigt för att hålla en sorts information. |
| 1NF | A table in which the intersection of every column and record contains only one value. |
| 2NF | a table that is in 1NF and every non-primary-key column is fully functionally dependent on the primary |
| 3NF | a table that is in 1NF and 2NF and in which no non-primary-key column is transitively dependent on the primary key |
| functional dependency | describes the relationship between columns in a table and indicates how columns relate to one another. For example, consider a table with columns a and b, where column a determines column b (denoted a → b). If we know the value of a, we find only one value of b in all the records that has this value for a, at any moment in time. However, for a given value of b there may be several different values of a. |
| Full functional dependency | is described when a and b are columns of a table, b is fully determined by a, if b is not determined by any subset of a. If b is determined by a sub- set of a, this is referred to as a partial dependency. |
| Transitive dependency | describes a relationship between columns a, b, and c. If a determines b (a → b) and b determines c (b → c), then c is transitively dependent on a via b (provided that b or c does not determine a). |
| relationell algebra | Ger en teoretisk grund till relationella databaser, ett medel för att göra förfrågningar. |
Want to create your own Flashcards for free with GoConqr? Learn more.