BAZY DANYCH model relacyjny. Opracował: dr inż. Piotr Suchomski

Podobne dokumenty
Definicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.

1 Wstęp do modelu relacyjnego

PLAN WYKŁADU BAZY DANYCH MODEL DANYCH. Relacyjny model danych Struktury danych Operacje Integralność danych Algebra relacyjna HISTORIA

PLAN WYKŁADU BAZY DANYCH ZALEŻNOŚCI FUNKCYJNE

Relacyjny model baz danych, model związków encji, normalizacje

Model relacyjny. Wykład II

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko

Wykład 2. Relacyjny model danych

Bazy Danych i Usługi Sieciowe

WYKŁAD 1. Wprowadzenie do problematyki baz danych

Normalizacja baz danych

Bazy danych i usługi sieciowe

030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

Pojęcie zależności funkcyjnej

Pierwsza postać normalna

Model relacyjny. Wykład II

BAZY DANYCH. Anomalie. Rozkład relacji i normalizacja. Wady redundancji

Bazy danych Wykład zerowy. P. F. Góra

Bazy danych. Andrzej Łachwa, UJ, /15

Normalizacja relacyjnych baz danych. Sebastian Ernst

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA Relacyjny model danych. Relacyjny model danych Struktury danych Operacje Oganiczenia integralnościowe

Plan wykładu: Relacyjny model danych: opis modelu, podstawowe pojęcia, ograniczenia, więzy.

Systemy baz danych. Notatki z wykładu

Relacyjny model danych

Jak wiernie odzwierciedlić świat i zachować występujące w nim zależności? Jak implementacja fizyczna zmienia model logiczny?

System zarządzania bazą danych SZBD (ang. DBMS -Database Management System)

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

Program wykładu. zastosowanie w aplikacjach i PL/SQL;

Pożyczkobiorcy. Anomalia modyfikacji: Anomalia usuwania: Konta_pożyczkowe. Anomalia wstawiania: Przykłady anomalii. Pożyczki.

Technologia informacyjna

Normalizacja. Pojęcie klucza. Cel normalizacji

Projektowanie Systemów Informacyjnych

Pierwsza postać normalna

Wykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.

Baza danych. Modele danych

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Baza danych. Baza danych to:

Bazy Danych. Model Relacyjny. Krzysztof Regulski WIMiIP, KISiM, B5, pok. 408

Cel normalizacji. Tadeusz Pankowski

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

BAZY DANYCH algebra relacyjna. Opracował: dr inż. Piotr Suchomski

Projektowanie relacyjnych baz danych

Program nauczania. Systemy baz danych. technik informatyk

Związki pomiędzy tabelami

SZKOLENIE: Administrator baz danych. Cel szkolenia

Bazy danych. Algebra relacji

Bazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych

Normalizacja schematów logicznych relacji

Podstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem. dr Jakub Boratyński. pok. A38

Technologie baz danych

S y s t e m y. B a z D a n y c h

Bazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski

1 Przygotował: mgr inż. Maciej Lasota

Normalizacja baz danych

Model relacyjny bazy danych

Projektowanie relacyjnych baz danych

Zasady transformacji modelu DOZ do projektu tabel bazy danych

Bazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski

FUNKCJE SZBD. ZSE - Systemy baz danych 1

Krzysztof Kadowski. PL-E3579, PL-EA0312,

Przestrzenne bazy danych Podstawy języka SQL

Systemy GIS Tworzenie zapytań w bazach danych

Agnieszka Ptaszek Michał Chojecki

Bazy danych w sterowaniu

Systemy baz danych. mgr inż. Sylwia Glińska

Bazy danych Teoria projektowania relacyjnych baz danych. Wykła. Wykład dla studentów matematyki

Relacyjny model danych

Transformacja modelu ER do modelu relacyjnego

Bazy Danych i Usługi Sieciowe

Ogólny plan przedmiotu. Strony WWW. Literatura BAZY DANYCH. Materiały do wykładu:

Teoretyczne podstawy informatyki

Bazy danych 3. Normalizacja baz danych

KaŜdemu atrybutowi A przyporządkowana jest dziedzina Dom(A), czyli zbiór dopuszczalnych wartości.

Bazy danych. Plan wykładu. Zależności funkcyjne. Wykład 2: Relacyjny model danych - zależności funkcyjne. Podstawy SQL.

Teoretyczne podstawy informatyki

Zależności funkcyjne pierwotne i wtórne

Księgarnia PWN: Michael J. Hernandez Bazy danych dla zwykłych śmiertelników

Bazy danych. Andrzej Łachwa, UJ, /14

Bazy Danych. C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000

BAZY DANYCH Podstawowe pojęcia

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

Projektowanie baz danych

K1A_W11, K1A_W18. Egzamin. wykonanie ćwiczenia lab., sprawdzian po zakończeniu ćwiczeń, egzamin, K1A_W11, K1A_W18 KARTA PRZEDMIOTU

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

PRZESTRZENNE BAZY DANYCH WYKŁAD 2

Bazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski

Projektowanie baz danych

Alicja Marszałek Różne rodzaje baz danych

Informatyka Ćwiczenie 10. Bazy danych. Strukturę bazy danych można określić w formie jak na rysunku 1. atrybuty

WPROWADZENIE DO BAZ DANYCH

Bazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,

Bazy danych. Dr inż. Paweł Kasprowski

Chemoinformatyczne bazy danych - Wprowadzenie do technologii baz danych. Andrzej Bąk

Instytut Mechaniki i Inżynierii Obliczeniowej Wydział Mechaniczny technologiczny Politechnika Śląska

PLAN WYKŁADU BAZY DANYCH GŁÓWNE ETAPY PROJEKTOWANIA BAZY MODELOWANIE LOGICZNE

Relacyjny model danych. Relacyjny model danych

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1

Bazy danych Algebra relacji Wykład dla studentów matematyki

WPROWADZENIE DO BAZ DANYCH

Bazy danych - wykład wstępny

Transkrypt:

BAZY DANYCH model relacyjny Opracował: dr inż. Piotr Suchomski

Relacyjny model danych Relacyjny model danych posiada trzy podstawowe składowe: relacyjne struktury danych operatory algebry relacyjnej, które umożliwiają tworzenie, przeszukiwanie i modyfikowanie danych ograniczenia (więzy) integralnościowe jawnie lub niejawnie określającymi możliwe/dopuszczalne wartości danych.

Relacja Podstawową strukturą danych modelu relacyjnego jest relacja, będąca podzbiorem iloczynu kartezjańskiego wybranych domen i przedstawiana w postaci dwuwymiarowej tabeli. W tym ujęciu pojęcia relacji (ang. relation) i tabeli (ang. table) są synonimami. Pojęcie relacji używane jest na poziomie teorii baz relacyjnych i modelu konceptualnego, a pojęcie tabeli na poziomie realizacji fizycznej.

Relacja Relacja (bazodanowa) jest to dowolny podzbiór produktu kartezjańskiego skończonej liczby dziedzin prostych. Dziedzina jest prosta, jeili jej elementy są nierozkładalne (atomowe). Niech D 1, D 2,,D n są to dziedziny proste, 0<n<, D 1 x D 2 x x D n to produkt kartezjański tych dziedzin prostych: zbiór wszystkich krotek (d 1, d 2,,d n ) takich, że d 1 D 1, d 2 D 2,, d n D n, Wartość n określa stopień relacji

Relacja Poszczególne pozycje krotek relacji nazywamy atrybutami relacji. Atrybuty relacji muszą być atomowe. Spełnienie tego wymogu jest warunkiem aby relacja była w pierwszej postaci normalnej (1NF).

Właściwości relacji wszystkie jej krotki są różne, wszystkie jej atrybuty są różne, kolejność krotek nie ma znaczenia i w ogólności nie jest ona znana, kolejność atrybutów nie ma znaczenia, wartości atrybutów są niepodzielne (atomowe), tj. nie mogą być zbiorem wartości.

Schemat relacji Nazwa relacji oraz zbiór jej atrybutów, umieszczonych wnawiasie, nazywany jest schematem relacji. Atrybuty w schemacie relacji nie są listami ale zbiorami. Jednak dla porządku ustala się standardowy porządek atrybutów i jest on wiążący w całym projekcie. Pracownik(nr_ewid, imie, nazwisko, stanowisko, dział) Samochód(nr_rej, marka, poj_silnika) Projekt relacyjnej bazy danych może składać się z jednego lub kilku schematów relacji. Zbiór schematów relacji nazywany jest schematem relacyjnej bazy danych.

Instancja relacji Relacja nie jest tworem statycznym, gdyż zmienia się w czasie. Zmiany te dotyczą poszczególnych krotek. Mogą pojawiać się nowe krotki, inne mogą być usuwane lub modyfikowane są wartości poszczególnych atrybutów. Stan relacji w danej chwili nazywany jest instancją relacji. W relacji zmianie może ulec również jej schemat, jednak takie operacje są bardzo kosztowne i zdarzają się rzadko.

Intensja i ekstansja relacji Z punktu widzenia semantyki (znaczenia) rozróżnia się dwa pojęcia - pojęcie intensji relacji oraz ekstensji relacji. Intensja relacji odpowiada znaczeniu relacji - predykat związany z relacją stanowi element jej intensji. Na intensję relacji mogą poza tym składać się inne jej własności. Ekstensja relacji jest zbiorem krotek spełniających własności, które stanowią intensję relacji. Własności te nazywa się warunkami integralności.

Intensja a ekstensja relacji Dla relacji R(PRZEDMIOT, DZIEŃ, GODZINA, SALA, WYKŁADOWCA): - intensję relacji wyrażają następujące warunki integralności: 1. predykat związany z relacją R mówi o tym, że wykładowca w prowadzi zajęcia z przedmiotu p w dniu d, o godzinie g, w sali s ; 2. dziedzina atrybutu GODZINA jest zbiorem liczb całkowitych z przedziału <7, 24>; 3. dany wykładowca moŝe znajdować się o określonej godzinie tylko w jednej sali. - ekstensję relacji R stanowi zbiór krotek spełniających własności (1), (2), (3).

Definicja zależności funkcyjnej Jeżeli dwie krotki relacji R są zgodne dla atrybutów A 1 A 2 A n, to muszą być również zgodne w pewnym innym atrybucie B. Zależność tą można zapisać: A 1 A 2 A n -> B, A 1 A 2 A n określają funkcyjnie B Jeśli zbiór atrybutów A 1,A 2,,A n określa więcej niż jeden atrybut B to można skrótowo zapisać: A 1 A 2 A n -> B 1 B 2 B m

Zależność funkcyjna

Klucze relacji Atrybut lub zbiór atrybutów {A1, A2,..., An} tworzy klucz relacji jeśli: wszystkie pozostałe atrybuty relacji są funkcyjnie zależne od tych atrybutów (nie może się zdarzyć aby dwie różne krotki relacji R były zgodne dla wszystkich atrybutów A1, A2,..., An) Nie istnieje taki podzbiór właściwy zbioru {A1, A2,..., An}, od którego pozostałe atrybuty relacji R są zależne funkcyjnie, tzn. klucz musi być minimalny Klucze w diagramach E/R nie spełniają drugiego wymagania

Nadklucze Nadklucz zbiór atrybutów, który zawiera klucz. Każdy klucz jest nadkluczem.

Wykrywanie kluczy w relacji Reguła 1 Jeśli relacja pochodzi z przekształcenia zbioru encji, to jej kluczem są atrybuty kluczowe tego zbioru encji Reguła 2 (dotyczy związków binarnych) Jeśli związek jest typu wiele do wiele, to klucze obu zbiorów encji objętych związkiem tworzą zbiór atrybutów klucza R jeśli związek ze zbioru encji E1 do zbioru encji E2 jest typu wiele do jeden, to atrybuty klucza E1 stają się kluczem R, ale atrybuty klucza E2 nie wchodzą do klucza relacji R. Jeśli związek jest typu jeden do jeden, to atrybuty klucza któregokolwiek ze zbiorów mogą być kluczem R. W tej sytuacji nie ma tylko jednego klucza.

Klucze relacji - notacja Klucze główne: Książki(ISBN, tytuł, autor, rok) Klienci(NIP, Nazwisko, adres, status) Książki(ISBN, tytuł, autor, rok) Klucze obce: Książki(ISBN, tytuł, autor, rok, id_wyd REF Wydawnictwo) Wydawnictwo(ident, nazwa, miasto) Klucz obcy Klucz obcy może wchodzić w skład klucza głównego.

Relacje a zbiory encji Reprezentacja zbiorów encji Każdy zbiór encji zamieniany jest na relację, której klucz główny jest równy kluczowi zbioru encji. Reprezentacja związków Związki 1:1 reprezentowane są przez klucz obcy wstawiany do jednej z relacji. Związki 1:n reprezentowane są przez klucz obcy wstawiany do relacji po stronie n. Związki n:m reprezentowane są przez dodatkową relację, której klucz główny powstaje ze złożenia kluczy głównych związanych zbiorów encji.

Relacje a zbiory encji Związek może być reprezentowany przez oddzielną relację również w przypadku związków 1:1 i 1:n co zapewni większą elastyczność i zapewni symetrię, natomiast wadą jest to, że powstaje dodatkowa relacja.

Relacje a zbiory encji - przykład Data PESEL PES_M PES_K PESEL Mężczyźni Małżeństwo Kobiety Schemat relacyjnej bazy danych: Mężczyźni(PESEL, imię, nazwisko, ) Kobiety(PESEL, imię, nazwisko, ) Małżeństwo(PES_M REF Mężczyźni, PES_K REF Kobiety, Data)

Anomalie aktualizacji Anomalie pojawiają się wtedy gdy do jednej relacji próbujemy włączyć zbyt wiele danych. Podstawową anomalią jest redundancja danych. W wielu krotkach pojawiają się te same dane. Problem modyfikacji relacji obarczonej anomalią polega na tym, że zmieniana wartość atrybutu musi być zmieniona we wszystkich krotkach relacji, w których ta wartość występuje. Problem usuwania danych. Wraz z usuwaną krotką można usuną dane, które mogą być przydatne. Istnieje również zagrożenie spójności i integralności danych.

Dekompozycja relacji Właściwym sposobem eliminacji anomalii jest dekompozycja relacji. Polega ona na podziale atrybutów relacji R na dwa nowe schematy relacji. Reguła dekompozycji dotyczy również krotek relacji R (podział danych do nowych relacji), dzięki operacji rzutowania krotek R.

Dekompozycja relacji Relację R o schemacie R(A 1,A 2, A n ) dekomponujemy między 2 relacje S i T o schematach S(B 1,B 2, B n ) i T(C 1,C 2, C n ) według następujących reguł: {A 1,A 2,,A n } = {B 1,B 2, B n } {C 1,C 2,,C n }, Krotki relacji S powstają przez rzutowanie wszystkich krotek relacji R na zbiór atrybutów {B 1,B 2,,B m }. Oznacza to, że z każdej krotki t z bieżącej instancji relacji R pobieramy wartości atrybutów B 1,B 2,,B m, i tworzymy w ten sposób krotkę relacji S, należącą do jej bieżącej instancji. Ponieważ relacje są zbiorami, więc taką samą krotkę S można uzyskać z rzutowania różnych krotek relacji R. W takich przypadkach w S umieszcza się tylko jedną kopię każdej krotki.

Dekompozycja relacji W podobny sposób z rzutowania krotek bieżącej instancji relacji R na zbiór atrybutów {C 1,C 2,,C k } otrzymuje się krotki relacji T.

Normalizacja PARTICIPANTS(IDENT, NAME, CITY, INHAB, COURSE, GRADE) Student o identyfikatorze IDENT i nazwisku NAME, pochodzący z miasta CITY, o liczbie mieszkańców INHAB, ukończył kurs COURSE, z oceną GRADE.

Normalizacja Tablica PARTICIPANTS wykazuje wiele anomalii ze względu na redundancję danych. Chcąc zmienić liczbę mieszkańców trzeba to zrobić w wielu wierszach (aby zachować integralność) Usuwając rekord danych o kursancie Rodin usuwane są również dane o liczbie mieszkańców miasta Aberdeen. Chcąc dodać informacje o innym kursie, który ukończył kursant trzeba też dodać dane, które w bazie już istnieją. Celem normalizacji jest usunięcie redundancji tak, by każda informacja była przechowywana w bazie tylko raz.

Zależności funkcyjne cd. Zbiór atrybutów B jest w pełni funkcyjnie zależny od zbioru atrybutów A w schemacie R, jeżeli A B i nie istnieje podzbiór A A taki, że A B. Zbiór atrybutów B jest częściowo funkcyjnie zależny od zbioru atrybutów A w schemacie R, jeżeli A B i istnieje podzbiór A A taki, że A B.

Druga postać normalna Relacja jest w 2NF jeżeli jest w pierwszej postaci normalnej (1NF) każdy atrybut niekluczowy jest w pełni funkcyjnie zależny od klucza głównego. Relacja PARTICIPANT nie jest w 2NF gdyż zawiera niepełne zależności funkcyjne: IDENT->NAME IDENT->CITY IDENT->INHAB

Druga postać normalna cd. Relację PARTICIPANT można sprowadzić do 2NF dokonując dekompozycji (projekcji) na dwie relacje: PART_COURSE(IDENT REF PART_DATA, COURSE,GRADE) PART_DATA(IDENT, NAME, CITY, INHAB)

Druga postać normalna Relacja PART_DATA nadal posiada redundancję. Jeśli kliku studentów pochodzi z tego samego miasta to w bazie powtarzać się będą dane dotyczące liczby mieszkańców. Powodem tego jest to, że atrybut INHAB zależy funkcyjnie od atrybutu niekluczowego CITY.

Zależności funkcyjne cd. Zbiór atrybutów B jest przechodnio funkcyjnie zależny od zbioru atrybutów A w schemacie relacji R, jeżeli A B i istnieje zbiór atrybutów C, nie będący podzbiorem żadnego klucza schematu relacji R taki, że zachodzi A C i C B. Zależność funkcyjna A B jest zależnością przechodnią jeżeli istnieje podzbiór atrybutów taki, że zachodzi A C, C B i nie zachodzi C A lub B C.

Trzecia postać normalna Relacja jest w trzeciej postaci normalnej (3NF) jeśli: Jest w 2NF, Żaden atrybut niekluczowy nie zależy przechodnio od klucza głównego. Relację PART_DATA można sprowadzić do 3NF przez dekompozycję na dwie relacje: PART_ID(IDENT, NAME, CITY REF CITIES) CITIES(CITY, INHAB)

Trzecia postać normalna

Postać normalna Boyce a Codda Wyznacznik to atrybut relacji (może być złożony), od którego w pełni funkcjonalnie zależy inny atrybut tej relacji. Relacja jest w normalnej Boyce a Codda (BCNF) wtedy i tylko wtedy, gdy każdy wyznacznik jest kluczem kandydującym. Postać BCNF jest silniejsza niż 2NF i 3NF.

Zależności wielowartościowe Niech istnieje relacja R i jej atrybuty A, B, C. Pomiędzy atrybutami A i B zachodzi zależność wielowartościowa (A->->B) wtedy i tylko wtedy, gdy dla każdej wartości A istnieje zbiór możliwych wartości B i ten zbiór nie zależy od C

Zależności wielowartościowe Obie tablice są w 3NF (klucz główny składa się ze wszystkich atrybutów).ale: W obu tablicach istnieje redundancja danych SSN->->LANGUAGE (bo znajomość języków nie zależy od uprawianych sportów), SSN->->SPORT (bo uprawiane sporty nie zależą od znanych języków)

Czwarta postać normalna Relacja jest w czwartej postaci normalnej (4NF) jeśli jest w 3NF oraz nie zawiera dwóch lub więcej zależności wielowartościowych. Relację PERSONS można sprowadzić do 4NF przez dekompozycję na dwie relacje: PER_LAN(SSN, LANGUAGE) PER_SPORT(SSN, SPORT)

Normalizacja - podsumowanie Dobrze zaprojektowana relacja składa się klucza głównego (prosty lub złożony) i z pewnej liczby niezależnych od siebie atrybutów, które tylko zależą od całego klucza głównego. W każdym przypadku normalizacja relacji wymaga jej dekompozycję na kilka innych relacji drogą projekcji.

Reguły Codd a Edgar Frank Codd znany brytyjski informatyk, zasłużony w rozwoju teorii relacyjnych baz danych. Opublikował 12 reguł (właściwie 13), których stopień spełnienia określa poziom relacyjności bazy danych.

12 reguł Codd a 0. Reguła zerowa. Aby można było uznać dany system za system zarządzania relacyjnych baz danych, musi on wykorzystywać (wyłącznie) relacyjne mechanizmy do zarządzania bazą danych. 1. Reguła informacyjna. Wymaganie, aby wszystkie informacje zawarte w bazie danych były przedstawiane w jeden i tylko jeden sposób, mianowicie za pomocą wartości umieszczanych w kolumnach w obrębie wierszy tabel

12 reguł Codd a 2. Reguła gwarantowanego dostępu: ta reguła jest zasadniczo powtórzeniem wymagania dotyczącego kluczy podstawowych. Stanowi ona, że każda poszczególna wartość skalarna w bazie danych musi mieć zapewnioną możliwość logicznego adresowania, wykorzystując nazwę zawierającej ją tabeli, nazwę zawierającej ją kolumny oraz wartość klucza podstawowego zawierającego ją wiersza

12 reguł Codd a 3. Uporządkowana obsługa wartości NULL: wymaga się, aby DBMS obsługiwał reprezentację brakujących informacji oraz informacji nieadekwatnych, tzn. odmiennych od wszystkich wartości prawidłowych, niezależnie od typu danych. Przyjmuje się, że DBMS musi obsługiwać taką reprezentację w uporządkowany sposób.

12 reguł Codd a 4. Aktywny katalog dostępny na bieżąco, oparty na modelu relacyjnym: wymaga się, aby system obsługiwał wbudowany katalog relacyjny z bieżącym dostępem dla uprawnionych użytkowników, używających ich zwykłego języka zapytań.

12 reguł Codd a 5. Reguła dotycząca pod-języka obsługi danych o pełnych możliwościach: system musi obsługiwać przynajmniej jeden język relacyjny, który: (a) charakteryzuje się liniową składnią; (b) może być używany zarówno w trybie interaktywnym, jak i w obrębie programów aplikacyjnych; (c) obsługuje operacje definiowania danych (łącznie z definiowaniem perspektyw), operacje manipulowania danymi (aktualizację i wyszukiwanie), ograniczenia związane z bezpieczeństwem i integralnością oraz operacje zarządzania transakcjami (rozpoczynanie, zapis zmian i ponowny przebieg).

12 reguł Codd a 6. Reguła aktualizacji perspektyw: wszystkie perspektywy, które teoretycznie dają się aktualizować, muszą być aktualizowane przez system. 7. Polecenia wstawiania, aktualizacji oraz usuwania w języku wysokiego poziomu: wymaga się, aby system obsługiwał operatory INSERT, UPDATE oraz DELETE dotyczące całych zbiorów.

12 reguł Codd a 8. Fizyczna niezależność danych. Programy za pomocą których manipuluje się bazą danych są niezależne od tego jak baza danych jest fizycznie zorganizowana 9. Logiczna niezależność danych. Programy, za pomocą których BD jest przetwarzana są niezależne od tego jak baza danych jest zorganizowana wewnętrznie. 10. Zasady, które artykułują semantyczny stopień integralności, powinny być możliwe do opisania wewnątrz języka zapytań DBMS. Możliwe powinno być również zmagazynowanie ich wewnątrz katalogu systemu BD i narzucanie przez sam system BD

12 reguł Codd a 11. Relacyjna BD powinna działać tak samo, niezależnie od tego, czy pracuje na pojedynczej maszynie czy jest udostępniana sieciowo. 12. Reguła nie prowadzenia "działalności wywrotowej": jeśli system jest wyposażony w interfejs niskiego poziomu (operacje na pojedynczych rekordach), nie może być użyty do prowadzenia działalności wywrotowej (np. omijania zabezpieczeń relacyjnych lub ograniczeń integralnościowych).