Pojęcia podstawowe
Bazy danych i ich użytkownicy
Baza danych jest zbiorem powiązanych danych. Baza danych jest abstrakcyjnym, informatycznym
odzwierciedleniem wybranego fragmentu rzeczywistości nazywanego miniświatem. Zmiany w miniświecie są odzwierciedlane w bazie danych.
Mówiąc o wybranym fragmencie rzeczywistoći mamy na myśli rzeczywistość dwojakiego rodzaju: fizyczną i konceptualną.
Rzeczywistość fizyczna to ta, którą postrzegamy na co dzień wokół nas. Przykładem takiej rzeczywistości może być uczelnia, w której dostrzegamy, z jakiej strony, pracowników, studentów, stażystów i zaproszonych gości, natomiast z drugiej strony - sale dydaktyczne, publikacje naukowe, indeksy itp.
Rzeczywistość konceptualna to ta, która istnieje zwykle w wyobraźni osób, które chcą ją dla określonych celów w bazie danych odzwierciedlić. Przykładem rzeczywistości konceptualnej jest projekt nowej wersji samochodu firmy Opel, którego wizja istnieje jedynie w sferze dyskusji i wyobraźni zespołu projektantów.
Baza danych jest logicznie spójnym zbiorem danych posiadających określone znaczenie. Logiczna spójność jest tu rozumiana jako wierność odwzorowania modelowanego miniświata. Baza danych nie może być w stanie, który nie jest nigdy osiągalny w modelowanym miniświecie. Przykładowo, baza danych, w której ewidencjonowani są studenci i pracownicy OWSIIZ nie może zawierać informacji o osobach, które w OWSIIZ nie studiują lub nie pracują.
Baza danych jest projektowana, budowana i wypełniana danymi dla określonych celów. Ma określoną grupę użytkowników korzystających w określony sposób z zawartych w niej informacji. Szczególnymi
użytkownikami są projektanci bazy danych, którzy definiują strukturę bazy danych i przygotowują programy (zwane często aplikacjami bazy danych), ułatwiające późniejsze korzystanie z bazy przez innych
użytkowników. Poprawnie zaprojektowana baza danych jest najpierw wypełniana danymi, a następnie przetwarzana. Wypełnianie i przetwarzanie danych jest realizowane zwykle przy użyciu udostępnionych przez projektantów aplikacji. Grupy użytkowników wypełniających bazę danych i przetwarzających ją mogą być rozłączne. Przykładowo, celem bazy danych przygotowanej dla potrzeb dziakanatu pewnej uczelni jest wspomaganie jej procesów dydaktycznych. Została ona zaprojektowana przez specjalistów z określonej firmy.
Z przygotowanych przez nich aplikacji korzystają różni użytkownicy: pracownicy dziekanatu, nauczyciele akademiccy i studenci. Pracownicy dziekanatu wypełnili bazę danych tak, aby możliwie najwierniej odzwierciedlała ona ich uczelnię. Nauczyciele akademiccy i studenci głównie przetwarzają bazę danych.
Sposób wykorzystania bazy danych przez nauczycieli różni się od sposobu jej wykorzystania przez studentów.
W szczególności, nauczyciele mogą wprowadzać i poprawiać oceny z zaliczeń prowadzonych przez nich przedmiotów, czego nie wolno robić studentom.
Każda baza danych posiada:
n swoje źródło danych, n swoich użytkowników,
n związki z reprezentowaną rzeczywistością System zarządzania bazą danych
System zarządzania bazą danych (SZBD) to zbiór programów umożliwiających tworzenie i eksploatację bazy danych.
SZBD jest oprogramowaniem ogólnego przeznaczenia ułatwiającym procesy definiowania, konstruowania i przetwarzania bazy danych dla różnych aplikacji:
n definiowanie bazy danych polega na specyfikacji typów danych przechowywanych w niej.
n konstruowanie bazy danych polega na zapamiętywaniu danych na nośniku kontrolowanym przez SZBD n przetwarzanie polega na generowaniu zapytań do bazy danych w celu wyszukania potrzebnych danych,
uaktualnianiu danych zgodnie ze zmianami zachodzącymi w miniświecie i generowaniu raportów o przechowywanych danych.
System bazy danych składa się z bazy danych i systemu zarządzania bazą danych. Został on przedstawiony na rysunku. Użytkownicy kontaktują się z systemem bazy danych za pośrednictwem tzw. transakcji. Transakcja stanowi elementarną jednostkę pracy, składa się z wielu niepodzielnych akcji, każdej z tych akcji odpowiada jedno odwołanie do SZBD. Użytkownik inicjuje swoje transakcje bądź przez bezpośrednie kierowanie do SZBD polecenia, bądź też pośrednio, prz użyciu wcześniej przygotowanych aplikacji bazodanowych, odwołujących się do SZBD.
Transakcja jest atomową jednostką pracy, taką że baza danych jest w stanie spójnym (tj. zgodnym z modelowanym miniświatem) przed i po zakończeniu transakcji. Inaczej mówiąc, jeśli dana transakcja jest
wykonana poprawnie, zmiany, które wprowadziła, będą pamiętane w bazie danych. W przeciwnym przypadku, wszystkie zmiany wprowadzone przez transakcję będą anulowane (wycofane).
Rys.
Każda baza danych umożliwia jednoczesną pracę wielu użytkowników. Oznacza to, że w każdej chwili współbieżnie jest przetwarzanych wiele transakcji. SZBD musi zapewnić odpowiedni komfort pracy swoim użytkownikom tak, aby mieli oni wrażenie, że SZBD jest im dedykowany, tzn. by nie odczuwali w żaden sposób działania innych użytkowników. Wymaga to stosowania specjalnych technik zarządzania transakcjami (moduł zarządzania transakcjami - rys.).
Drugim ważnym modułem SZBD jest moduł zarządzania dostępem do danych. Umożliwia on właściwą interpretacje danych przechowywanych na urządzeniach zewnętrznych, wprowadzanie nowych danych oraz usuwanie i moyfikowanie istniejących danych.
Baza danych to dane i tzw. schemat. Dane opisują cechy (własności) modelowanych obiektów miniświata. Nie mogą być one jednak właściwie interpretowane bez użycia schematu. Schemat jest opisem struktury (formatu) przechowywanych danych oraz wzajemnych powiązań między nimi. Innymi słowy, schemat jest swego rodzaju „przyrządem optycznym”, którego użycie jest niezbędne do wyłowienia z bazy danych interesujących nas informacji.
Przykładowa baza danych
Na czterech kolejnych rysunkach przedstawiono przykładową zawartość bazy danych, służącej do
wspomagania procesu dydaktycznegopewnej uczelni. Na rys. zilustrowano strukturę danych modelującą jej studentów oraz informacje dotyczące dwóch przykładowych studentów. Każdy z nich jest opisany
nazwiskiem, numerem indeksu, rokiem studiów oraz kierunkiem studiów. Na rys. 3 zilustrowano strukturę informacji o prowadzonych w uczelni wykładach. Na rys.4 przedstawiono strukturę informacji dotyczących grup studenckich, natomiast na rys. 5 - informacji dotyczących zaliczeń modułów dydaktycznych.
STUDENT Nazwisko Nr indeksu Rok Kierunek
Nowak
Kowalik 18175
33573 I
II informatyka
telekomunikacja Rys.2 Studenci
WYKŁAD Nazwa Nr L_godz. Prowadzący
Języki programowania Bazy danych
Systemy opreacyjne
CS201 CS100 CS203
I2020 15
Kowalski Malinowski Nowakowski Rys.3 Prowadzone wykłady
GRUPA Nr grupy Nr wykładu Semestr Rok
85
92 CS201
CS445 letni
zimowy 2004
2005 Rys.4 Grupy studenckie
OCENY Nr indeksu Nr grupy Nr wykłady Ocena
18175 19551 33573
92101 112
CS100 CS445 CS100
45 3 Rys.5. Oceny z zaliczeń modułów dydaktycznych
Własności bazy danych
Bazy danych charakteryzują się czterema podstawowymi własnościami:
1. Niezależność aplikacji i danych. Cecha ta ma dwa aspekty. Po pierwsze, dane mogą być wprowadzane do bazy danych bez konieczności modyfikowania korzystających z nich aplikacji. Po drugie, aplikacje mogą być modyfikowane, np. w celu ich ulepszania, niezależnie od stanu bazy danych.
2. Abstrakcyjna reprezentacja danych. Przygotowanie aplikacji bazy danych jest realizowane przy użyciu tzw. deklaratywnych języków programowania (imperatywnych). Przykładowo, twórca aplikacji nie interesuje się kolejnością danych w bazie danych ani też sposbem ich reprezentowania i wyszukiwania.
Precyzuje jedynie warunki selekcji informacji, co oznacza, że pracuje w kategoriach „co zrobić”, a nie
„jak zrobić”.
3. Różnorodność sposobów widzenia danych. Te same dane mogą być „widziane” w różny sposób przez różnych użytkowników. Uzyskuje się to, np. dzięki stosowaniu szczególnych filtrów (nazywanych perspektywami), które są nakładane na te same dane.
4. Fizyczna i logiczna niezależność danych. Fizyczna niezależność danych polega na tym, że rozszerzanie systemu komputerowego, na którym pracuje SZBD o nowy bardziej efektywny sprzęt (wymiana jego wybranych elementów) nie narusza danych w bazie danych. Logiczna niezależność danych ma dwa aspekty. Po pierwsze, wprowadzanie nowych danych do bazy danych nie dezaktualizuje starych danych. Po drugie, dane, które nie są wzajemnie powiązanie tzw. związkami integralnościowymi, mogą być usuwane z bazy niezależnie od siebie.
Stosowanie baz danych w celu informatyzacji określonej dziedziny wiąże się z pewnymi niedogodnościami występującymi zwłaszcza w poczętkowym okresie ich wdrażania.
Wśród podstawowych korzyści wynikających ze stosowania baz danych wyróżniamy:
n zmniejszenie nadmiarowaści przechowywanych danych polegające na tym, że dane wykorzystywane przez różne aplikacje nie są nigdy duplikowane. W konsekwencji, ułatwia to zachowanie ich poprawności.
n współdzielenie danych, które ma dwa aspekty. Po pierwsze, na tych samych danych mogą współbieżnie pracować różne aplikacje, bez zagrożenia wzajemnego ich niszczenia. Po drugie, na tych samych danych może pracować współbieżnie ta sama aplikacja, wywołana wielokrotnie i asynchronicznie przez różnych użytkowników bazy danych.
n autoryzacja dostępu do danych uniemożliwiająca użytkowanie poufnych danych przez niepowołanych użytkowników.
n wielość interfejsów do danych polegająca na możliwości wyświetlania (wizualizacji) tych samych danych w różnych formatach, np. w postaci znakowych lub graficznych formularzy.
n reprezentacja złożonych związków pomiędzy danymi polegająca na tym, że za pomocą prostych, intuicyjnie dobrze zrozumiałych mechanizmów można modelować związki semantyczne pomiędzy różnymi danymi.
n ograniczenia integralnościowe będące zabezpieczeniem przed wpisywaniem do bazy danych niewłąściwych wartości i zabezpieczeniem przed niewłaściwymi związkami między nimi.
n ochrona przed awariami systemu polegająca na uodpornieniu SZBD w taki sposób, że po wystąpieniu nieprzewidzianej awarii, np. zaniku napięcia zasilającego istnieje możliwość odtworzenia poprawnego stanu bazy danych sprzed awarii.
Kiedy zatem nie zaleca się stosowania baz danych.
n w przypadku ograniczenia możliwości finansowych. Stosowanie baz danych wiąże się z wysokim początkowymkosztem inwestycji, wynikającym z konieczności zakupu drogiego systemu zarządzania bazą danych oraz nowego lub dodatkowego sprzętu, bez którego SZBD nie może pracować lub nie pracuje efektywnie.
n w przypadku gdy mechanizmy SZBD w zakresie współbieżności dostępu, bezpieczeństwa, odtwarzania po awarii oraz definiowania ograniczeń integralnościowych są nadmiarowe.
n w przypadku przetwarzania danych przez pojedynczego użytkownika lub grupę użytkownikó pracujących w sposób ściśle skoordynowany (np. sekwencyjny).
n w przypadku przechowywania prostych danych o niskim stopniu wzajemnego powiązania oraz używania prostych programów, które nie będą rozwijane w przyszłości.
n w przypadku istotnych ograniczeń czasowych nakładanych na czas realizacji transakcji, np. ograniczeń czasu rzeczywistego.
Modele danych
Fundamentalną cechą systemów baz danych jest zapewnienie wyższego poziomu abstrakcji widzenia danych przez użytkowników, dzięki przesłonięciu szczegółów dotyczących fizycznej organizacji tych danych.
Uzyskuje się to dzięki oferowanym przez bazy danych modelom danych. Przez model danych rozumiemy zbiór pojęć stosowanych do opisu struktury bazy danych.
Struktura ta obejmuje:
n typy danych, związki pomiędzy danymi i ograniczenia nałożone na dane;
n zbiór operacji służących do definiowania, wyszukiwania i uaktualniania bazy danych.
Wśró modeli danych można wyróżnić następujące kategorie:
n koncepcyjne modele danych, zwane modelami konceptualnymi lub semantycznymi. Są to modele najbardziej zbliżone poziomem abstrakcji do wymagań projektantów bazy danych, stosowane w pierwszych etapach projektó w celu weryfikacji wyróżnionych w miniświecie obiektów i związków między nimi.
n inplementacyjne modele danych stosowane to transformacji wcześniej przygotowanego modelu koncepcyjnego do konkretnego modelu danych bazy danych, a więc do postaci, która jest zgodna z wymaganiami określonego SZBD. Wśród modeli implementacyjnych wyróżniamy modele:
hierarchiczny, sieciowy, relacyjny i obiektowy. Modele hierarchiczne i sieciowe nie są już stosowane w praktyce. Model relacyjny, dominuje w komercyjnych bazach, stosowany jest w bazie danych Oracle.
n fizyczne modele danych, określające sposoby organizacji danych w pamięci zewnętrznej komputera.
Modele te można rozpatrywać w sposób bardziej lub mniej szczegółowy: przy najwyższym stopniu szczegółowości rozważa się poszczególne bity przechowywane w pamięci, ich znaczenie i adres.
Natomiast na niższym stopniu szczegółowości operuje się pojęciami takimi jak: rekord i plik.
Języki baz danych
Użytkownik (projektant) bazy danych ma do dyspozycji zwykle cztery różne języki, które są ze sobą zintefrowane.
n Język definiowania danych (Data Definition Language - DDL), który umożliwia definiowanie struktury danych przechowywanych w bazie danych, a więc tworzenie schematu (implementacyjnego).
n Język manipulowania danymi (Data Manipulation Language - DML), który umożliwia wypełnianie bazy nowymi danymi, ich aktualizację i usuwanie.
n Język sterowania danymi (Data Control Language - DCL), który umożliwia użytkownikami bazy danych sterowanie jego transakcjami, np. ich wycofanie i zatwierdzanie.
n Język zapytań (Query Language), który umożliwia pobranie z bazy danych informacji zgodnych z wyspecyfikowanymi warunkami.
Metodyka projektowania baz danych
Metodyka konstruowania koncepcyjnego modelu danych dla relacyjnych baz danych oparta o tzw. model związków encji składa się z kliku kroków.
Pierwszym krokiem projektowania (rys.6) jest wyróżnienie fragmentu rzeczywistości - miniświata - który chcemy modelować w bazie danych. Natępnie, przeprowadzamy precyzyjną analizę tego miniświata, w wyniku której otrzymujemy jego model koncepcyjny, reprezentowany m.in. przez tzw. diagramy związków encji.
Drugim krokiem jest transormacja modelu koncepcyjnego do wybranego modelu implementacyjnego (zazwyczaj relacyjnego), której wynikiem są tzw. schematy relacji.
Schematy relacji muszą następnie zostać poddane tzw. procesowi normalizacji, który prowadzi do ich ulepszenia polegającego na takim przekształceniu, aby oczyścić je z niepożądanych własności. W praktyce, proces normalizacji jest wspomagany przez narzędzia projektowania aplikacji baz danych.
Ostatnimi etapami są dobór właściwych struktur fizycznych bazy danych, np. indeksów oraz tzw. strojenie systemu (system tuning) polegające na zwiększeniu jego efektywności przy użyciu mechanizmów dostępnych w SZBD. Etapy te są zwykle realizowane przez administratorów bazy danych.
Rozszerzony model związków encji Encje i atrybuty
Podstawowymi konstruktorami rozszerzonego modelu związków encji są: encje, atrybut i związek.
Próba modelowania w systemie komputerowym dowolnego wycinka rzeczywistości wiąże się z koniecznością rozpoznania występujących w nim obiektów. Wyróżniamy dwa rodzaje takich obiektów:
n obiekty materialne, np. człowiek, samochód, budynek;
n obiekty koncepcyjne, np. zamówienie, prasa, kurs, wydział.
Każdy z obiektów (materialny lub koncepcyjny) jest nazywany w modelu EER (Extended Entity Relationship) encją. Rozróżnianie encji jest możliwe dzięki temu, że ich odpowiedniki - obiekty mają określoną tożsamość.
Encje tego samego typu można grupować w zbiory. Mówimy wtedy o zbiorach encji. Konkretne encje często są nazywane wystąpieniami odpowiednich zbiorów. Każda z encji jest określana jednoznacznie za pomocą odpowiedniej nazwy. Encje, w szczególności pochodzące z różnych zbiorów encji, różnią się nie tylko nazwami, ale często również własnościami. Do modelowania tych własności służą atrybuty.
Atrybuty encji możemy pogrupować następująco:
n atrybuty jedo- i wielowartościowe; przykładem atrybutu jednowartościowego jest wiek encji Pracownik, natomiast atrybutu wielowartościowego - adres, który składa się z nazwy ulicy, miasta, kodu
pocztowego i kraju;
n atrybuty wyprowadzane, tj. takie, których wartość nie jest przechowywana w bazie danych, a jedynie obliczana (wyprowadzana) na podstawie wartości innych atrybutów; przykładem atrybutu
wyprowadzanego są oszczędności bankowe pracownika obliczane na podstawie pamiętanych jawnie stanów poszczególnych kont;
n kluczowe i niekluczowe (wtórne); atrybuty kluczowe, w odróżnieniu od niekluczowych, jednoznacznie identyfikują encję, np. numer rejestracyjny samochodu;
n klucze obce (foreign key), tj. atrybuty, które są kluczowe w innym zabiorze encji, np. niekluczowy atrybut dostawca zbioru encji Towary jest kluczem zbioru encji Dostawcy;
n obowiązkowe i opcjonalne; atrybuty obowiązkowe występują w każdej encji określonego zbioru, podczas gdy atrybuty opcjonalne mogą być w niektórych encjach pominięte;
n puste i niepuste; atrybuty puste są atrybutami obowiązkowymi, które mogą mieć nieokreślone (puste) wartości (null values); atrybuty niepuste muszą być zawsze określone.
Atrybuty kluczowe decydują o zakwalifikowaniu encji do grupy tzw. encji silnych. Encja, Która nie posiada atrybutów kluczowych jest nazwana encją słabą. Encje słabe nie mogą istnieć samodzielnie, a jedynie w powiązaniu z innymi encjami, z których conajmniej jedna musi być encją silną, wskazywaną z encji słabej przez klucz obcy. Przykładowo, encja Zamówienie posiadająca atrybut kluczowy numer_zamówienia jest encją silną. Jeżeli jednak encja ta nie posiada atrybutu numer_zamówienia, a jedynie atrybut zamawiający, będący kluczem obcym encji Klienci, to encja słaba, której istnienie jest warunkowane istnieniem powiązanej z nią encji ze zbioru Klienci.
Związki
Encje same przez się niosą niepełną informację. Z faktu, że encje Iwona i Piotr są elementami zbioru encji Pracownicy, a encje sekretarka i profesor - elementami zbioru Etaty, wynika jedynie to, że oba zbiory istnieją.
Jeżeli chcemy natomiast przechowywać w systemie informacje o tym, że Iwona jest zatrudniona w pewnej uczelni na etacie sekretarki, a Piotr na etacie profesora - jest konieczne wprowadzenie związku, np. o nazwie pracuje_na_etacie pomiędzy dwoma zbiorami encji: Pracownicy i Etaty. Zbiory encji połączone określonym związkiem niekoniecznie muszą być różne. W celu zapamiętania faktu, że Piotr jest przełożonym Pawła należy wprowadzić związek zwrotny, np. o nazwie zależności_służbowe, pomiędzy zbiorem encji Pracownicy i nim samym.
Z formalnego punktu widzenia, związek jest relacją R pomiędzy n zbiorami encji E1, E2, ...., EN. Liczba wiązanych zbiorów encji określa się tzw. stopniem związku. Najczęściej mamy do czynienia ze związkami o stopniu nie przekraczającym drugiego:
n unarnym (jednoargumentowym), n binarnym (dwuargumentowym).
W praktyce, w celu uniknięcia związków wyższego stopnia niż binarny, wprowadzna jest dodatkowa sztuczna encja, a związek wyższego stopnia jest zastępowany wieloma związkami binarnymi.
Na rys. zilustrowano związek binarny pracuje pomiędzy zbiorami Pracownik i Instytut, natomiast na rys.
związek ternarny dostawa pomiędzy zbiorami encji Projekt, Dostawca i Część.
Każdy związek jest opisany tzw. typem asocjacji, określającym liczbę encji z określonych zbiorów encji, które wchodzą w dany związek. W przypadku związków binarnych, wyróżniamy trzy podstawowe typy asocjacji:
n 1:1 n 1:n n m.:n
W związku typu 1:1, jedna encja pierwszego zbioru jest związana z dokładnie jedną encją drugiego zbioru (i odwrotnie). W przypadku związku 1:m., z jedną encją pierwszego związku może być związanych n encji drugiego zbioru. W najbardziej ogólnym związku m.:n, z jedną encją pierwszego zbioru może być związanych n encji drugirgo zbioru i odwrotnie - jedna encja pierwszego zbioru może być związana z m. encjami
pierwszego zbioru.
Poza stopniem i typem, każdy związek jest rónież opisany przez jedną z dwóch klas przynależności:
n opcjonalną (częściową), n obowiązkową (całkowitą).
W pierwszym przypadku w łączonych związkiem zbiorach encji dopuszcza się istnienie encji, któ®e nie są związane, natomiast w drugim wszystkie encje zbiorów muszą być wzajemnie powiązane.
Na rysunku przedstawiono sześć przykłądowych związków zbiorów encji oraz sposobów oznaczania ich stopni, typów i klas przynależności. Encje reprezentujemy za pomocą prostokątów o zaokrąglonych narożnikach, a związki - za pomocą linii łączących odpowiednie encje. Linia ciągła doprowadzona do encji oznacza jej obowiązkowość w związku, a przerywana - opcjonalność. Typ asocjacji różny od 1:1 oznaczamy
dodatkowo przez rozwidlenie linii reprezentującej związek w miejscu jej połączenia z odpowiednią encją, tj.
encją, która w związku może wystąpić wielokrotnie.
Raczej nienaturalny związek jest_w_związku jest związkiem unarnym, 1:1, opcjonalnym (są pracownicy któ®zy są w jakimś związku z dokładnie z jednym pracownikiem). Związek pracuje_dla
(jest_wpomagany_przez) jest związkiem binarnym, 1:m., opcjonalnym od strony encji Pracownik (każda sekretarka pracuje dla co najmniej jednego pracownia; są pracownicy, którzy nie są wspomagani przez żdaną sekretarkę). Związek jest_dyrektorem (jest_kierowany_przez) jest związkiem binarnym, 1:1, obustronnie opcjonalnym (są pracownicy, którzy są dyrektorami dokładnie jednego instytuty; są instytuty, które nie mają dyrektorów lub ich dyrektorzy nie pochodzą ze zbioru encji Pracowni). Związek należy_do jest związkiem binarnym, m.:n, opcjonalnym od strony encji Pracowni (pracowni może należeć do wielu organizacji; każda organizacja zrzesza co najmniej jednego pracownika; są pracownicy, którzy nie należą do żadnej organizacji).
W pewnych sytuacjach związki mogą być modelowane za pomocą atrybutów encji. Dotyczy to związkó typu 1:1 i 1:n. Na rysunku przedstawiono alternatywne sposoby modelowania informacji o tym, że każda encja zbioru Pracownik jest zatrudniona w jednym instytucie. W pierwszym przypadku, wyróżniono zbiór encji Instytut i powiązano go związkiem binarnym, typu 1:n, obowiązkowym ze zbiorem Pracownik. W drugim przypadku, rozszerzono zbiór atrybutów encji Pracownik o atrybut: nazwa_instytutu i adres_instytutu.
Zauważmy, że pominięcie encji Instytut jest niewłaściwe, np. w przypadku, gdy jest konieczne modelowanie faktu, że instytuty są jednostkami organizacyjnymi określonych uczelni (będących elementami zbioru encji Uczelnia).
W rozszerzonym modelu związków encji wprowadzono koncepcję hierarchii podzbiorów i generalizacji. Zbiór encji E1 jest podzbiorem zbioru innej encji E2, jeżeli każde wystąpienie encji E1 jest jednocześnie
wystąpieniem encji E2. Przykładowo, zbiór encji Sekretarka jest podzbiorem zbioru encji Pracownik.
Podobnie, zbiór encji Młody_Pracownik jest podzbiorem zbioru encji Pracownik. Podzbiory: Sekretarka i Młody_Pracowni nie muszą być rozłączne. Większość sekretarek jest jednocześnie młodymi pracownikami.
Zbiór encji E jest generalizacją zbiorów encji E1, E2, ..., En, jeżeli każde wystąpienie jednego i tylko jednego zbioru encji E1, E2, ...En. Zauważmy, że w przypadku hierarchii generalizacji jest wymagana rozłączność zbiorów E1, E2, ..., En. Ponadto, nie dopuszcza się istnienia takich encji w E, które nie są elementami jednego ze zbiorów E1, E2, ..., En.
Modelowanie koncepcyjne
W dużym uproszczeniu, proces modelowania koncepcyjnego składa się zwykle z trzech podstawowych etapów:
1. Określenia wymagań odnośnie do systemu informatycznego z punktu zamawiającego.
2. Zdefiniowanie informacji o obiektach i ich wzajemnych związkach. Wynikiem tego etapu jest kompletny diagram związków encji.
3. Określenie hierarchii funkcji, które mają być realizowane w systemie informatycznym.
