Algorithm FindPrimaryKey(Table T)

Input: Table T with attributes A1, A2, ..., An

Foreign Key Bulma Algoritması
Output: Primary key attribute(s)
Algorithm FindForeignKeys(Database D)

Input: Set of tables T1, T2, ..., Tn with attributes and

1. For each attribute Ai in T:
primary keys
Check if all values in Ai are unique (no duplicates)
Output: Foreign key relationships between tables
If unique and not null:
1. For each table Ti in D:
Mark Ai as candidate key
For each attribute Aj in Ti:
2. If no single attribute is unique:
For each table Tk in D (k ≠ i):
For each combination of attributes {Ai, Aj, ...}:
If (domain/type of Aj == domain/type of
Check if combination is unique
PK(Tk)) AND

(values of Aj ⊆ values of PK(Tk)):

If unique:

Mark this combination as candidate key

Then mark Aj as FOREIGN KEY
3. From all candidate keys: referencing PK(Tk)
Choose the smallest (minimum number of attributes) as
2. Return list of all foreign key relationships.
PRIMARY KEY.

4. Return chosen PRIMARY KEY.

ER Model INITIAL DESIGN

DATA REQUIREMENTS
This database is designed to manage the relationships
among employees, departments, projects, and dependents
within a company.
Each Employee is identified by a unique SSN and has
attributes such as name, address, salary, and birth date.
Every employee works for one Department and may DATA REQUIREMENTS DEVAMI
optionally be supervised by another employee. Each
Department has a unique name and number, one
manager, and can have multiple locations. Every Project is
controlled by a specific department, has a location, and can
involve multiple employees.
The Works_on relationship records which employees work
on which projects and the number of hours they spend.
The Dependent entity stores information about each → Total participation (her çalışan bu alt türlerden
employee’s dependents, such as their name, birth date, sex, birine ait olmalıdır)
and relationship to the employee. The Supervision
relationship represents the hierarchy between managers 2. MANAGER (Yönetici) Sub-Entity
and subordinates.
Manager_ID = Employee_ID
Overall, this structure provides a complete representation of
a company’s organizational hierarchy, projects, and Ek öznitelikler: Bonus, Level.
employee-dependent relationships.
Her yönetici en az bir departmandan sorumludur.
→ MANAGER ↔ DEPARTMENT arasında 1-to-M relationship
(Manages)
→ Total participation by MANAGER, Partial by
Yeni Requirement Ekleme DEPARTMENT

“Her çalışanın şirkette çalıştığı pozisyon (Job Position) Her yönetici ayrıca bazı çalışanları denetleyebilir.
bilgisi tutulmalıdır. → Bu durum recursive relationship (Supervises) ile
Her pozisyonun bir adı (Title), bir maaş aralığı modellenir:Bir manager, bir veya birden fazla employee’ı
(Min_Salary–Max_Salary) ve departmanla ilişkisi [Link] employee, sıfır veya bir manager
bulunmalıdır. tarafından denetlenebilir.
Bir pozisyonda birden fazla çalışan olabilir.”
3. ENGINEER (Mühendis) Sub-Entity
İlişki:Her departman, birden fazla job tanımlayabilir.
Engineer_ID = Employee_ID
→ 1:N (DEPARTMENT → JOB)
Ek öznitelikler: Skill_Set, Certification
Her çalışan, bir job’da çalışır.
→ N:1 (EMPLOYEE → JOB) Her mühendis bir veya daha fazla projede ve
departmanda çalışabilir.
Bu durumda department atamaları sadece job üzerinden
→ ENGINEER ↔ PROJECT arasında M:N relationship
yönetilecekse Works for ilişkisini kaldı[Link]ğer türlü
(Works_On)
Works for ilişkisinin kalması gerekir bu durumda tasarımı iyi
ayarlamak lazım. Her mühendis en az bir projede yer almalıdır (Total
participation by ENGINEER).Her proje mühendis
Bir employee kaydı eklersek nerelere kesinlikle kayıt
içermek zorunda değildir (Partial by PROJECT)
eklememiz gerekir?
4. TECHNICIAN (Teknisyen) Sub-Entity
Öncelikle Employee tablosuna eklememiz gerekir.
Technician_ID = Employee_ID
Eğer çalışan kişinin çalışacağı departman halihazırda
mevcutsa yeni bir departman kaydı eklememize gerek yok Ek öznitelikler: Expertise_Area, Experience_Years
yeni bir departman açılacaksa departman kaydı eklememiz
gerekir. Teknisyenler yalnızca projelerde çalışabilir.
→ TECHNICIAN ↔ PROJECT arasında M:N relationship
Aynı şekilde yeni çalışan halihazırda bir projeye atanıyorsa (Assigned_To_Project)
proje kaydı eklememiz gerekmez. → Teknisyenlerin department ile doğrudan ilişkisi
yoktur, sadece projeler aracılığıyla görev alırlar.
Dependents tablosuna kayıt ekleme mecbur değildir ailesi
olmayabilir. 5. DEPARTMENT (Departman) Entity
Works on tablosuna bir kayıt eklememiz gerekir burda Dept_ID primary key.Öznitelikler: Dept_Name, Location
relationship gibi gözüksede attributea sahip olduğu için bir
tablodur aslında ve employee ve proje arasında çift çizgi Her departman bir manager tarafından yönetilir.
yani mecburiyet olduğu için çalışanın bir projede çalışması → Total participation by DEPARTMENT and MANAGER
[Link] yüzden Works on tablosuna çalışanın hangi
projede kaç saat çalıştığı eklenmelidir. Her departman bir veya daha fazla çalışana sahip
olabilir.
ERDAN EER ÇEVİRMEK İÇİN YENİ DATA
REQUIREMENTLAR Bazı projeler birden fazla departman tarafından
yürütülebilir.
1. EMPLOYEE (Çalışan) Entity
PROJECT ile DEPARTMENT arasında M:N
Her çalışanın benzersiz bir Employee_ID’si vardır (Primary
Key).Öznitelikler: Name, Address, Salary, Hire_Date 6. PROJECT (Proje) Entity

Her çalışan bir veya birden fazla departmanda görev alabilir. Project_ID primary key.
→ Bu durum M:N relationship (Assigned_To) ile temsil
Öznitelikler: Project_Name, Budget, Start_Date,
edilir.
End_Date
→ Bir çalışan en az bir departmanda görev almalıdır
(Total participation by Employee). Her proje bir veya daha fazla departman tarafından
Çalışanlar, specialization (özelleştirme) yoluyla alt Her proje bir proje sorumlusuna sahip olabilir.
türlere ayrılır: → PROJECT ↔ EMPLOYEE arasında 1-to-1 relationship
(Project_Leader)
Manager, Engineer, Technician
→ Disjoint specialization (bir çalışan yalnızca bir alt Proje sorumlusu herhangi bir çalışan olabilir, yönetici
türdedir) olmak zorunda değildir.
Partial participation by PROJECT, Partial by arasında Works for ilişkisi yok.
EMPLOYEE

Her proje bir veya daha fazla engineer veya technician

içerir (Works_On ve Assigned_To_Project ilişkileri).

7. DEPENDENT (Bağımlı) Entity

Dependent_Name + Employee_ID birlikte Primary Key

oluşturur.

Öznitelikler: BirthDate, Relationship

Her Dependent, yalnızca bir employee’ye bağlıdır.

DEPENDENT ↔ EMPLOYEE arasında 1-to-M relationship

(Has)

Total participation by DEPENDENT (çalışan olmadan

dependent var olamaz).

Partial participation by EMPLOYEE (her çalışanın

dependent’ı olmak zorunda değil).

Dependent varlığı Weak Entity olarak modellenir.

→ Tanımlayıcı (owner) varlık: EMPLOYEE
→ Kısmi anahtar: Dependent_Name

Relational model
discovery/ER model discovery

Burda Bağımlılığı en az olandan başlayıp tüm relationshipleri

gezmeye çalışıyoruz bir entitye başladıysak onu bitirmemiz
gerekir.

Burda önemli kısım!!

Employee ve department arasında Works for ilişkisi kurmak

yerine engineerla kurduk çünkü employee ile kursak tüm
subentityleri kapsayacaktı ama technician ve department
Verilen ER yada EER diyagramı
methodologye göre
dönüştürme/MAPPING
Bu kısım 9 Adımdan oluşur ama sınavda 7 sinden
sorumluyuz.

 ER-to-Relational Mapping Algorithm

 Step 1: Mapping of Regular Entity Types

 Step 2: Mapping of Weak Entity Types

 Step 3: Mapping of Binary 1:1 Relation

Types

 Step 4: Mapping of Binary 1:N Relationship

Types.

 Step 5: Mapping of Binary M:N

Relationship Types.

 Step 6: Mapping of Multivalued attributes.

  Step 7: Mapping of N-ary Relationship Bu durumda, DEPARTMENT tablosuna ManagerSSN
Types. adında bir foreign key eklenir.
 Mapping EER Model Constructs to DEPARTMENT(DNUMBER, DNAME, MGR_SSN)
Relations
FOREIGN KEY (MGR_SSN) REFERENCES
 Step 8: Options for Mapping Specialization
or Generalization.
EMPLOYEE(SSN)

 Step 9: Mapping of Union Types 2. Yöntem: Merged Relation (Tek tabloya

(Categories). birleştirme)

Step1: Eğer her iki taraf da tam katılımlı (total

participation) ise, bu iki varlık ve aralarındaki ilişki
Her normal (güçlü) varlık türü (entity type) için, ER
tek bir tablo içinde birleştirilebilir.
şemasındaki bu varlığa karşılık gelen bir ilişki (relation /
tablo) oluşturulur. Bu yöntem genellikle her iki varlık da “zorunlu”
Bu tablo, varlığın tüm basit (simple) özniteliklerini içerir. olduğunda uygundur.

Varlığın birincil anahtarı (primary key) olarak, Örnek:

anahtar özniteliklerinden biri seçilir. Eğer her EMPLOYEE bir DEPARTMENT yönetiyorsa ve
her DEPARTMENTin bir EMPLOYEE yöneticisi varsa, iki
Eğer anahtar bileşik (composite) bir anahtar ise,
tabloyu birleştirmek mümkündür:
onu oluşturan tüm basit öznitelikler birlikte
primary key olarak atanır.
EMPLOYEE_DEPARTMENT(SSN, DNUMBER, DNAME,
EMPLOYEE(SSN, Name, Address, Salary, ...) SALARY, ...)

DEPARTMENT(DNUMBER, NAME, Locations, ...) 3. Yöntem: Cross-Reference Relation (Üçüncü

tablo oluşturma)
PROJECT(PNUMBER, PNAME, Location, ...)
Bu yaklaşımda, iki varlık arasındaki ilişkiyi temsil
SSN → EMPLOYEE tablosunun primary key’i etmek için ayrı bir üçüncü tablo oluşturulur.
Bu tablo, her iki varlığın primary key’lerini foreign
DNUMBER → DEPARTMENT tablosunun primary key’i key olarak içerir.

PNUMBER → PROJECT tablosunun primary key’i Örnek:

MANAGES(SSN, DNUMBER)
Step 2:
FOREIGN KEY (SSN) REFERENCES EMPLOYEE(SSN)
Zayıf varlığın tüm basit öznitelikleri (veya bileşik
özniteliklerin basit bileşenleri) eklenir. FOREIGN KEY (DNUMBER) REFERENCES
Ayrıca, sahip varlık (owner entity) olan güçlü varlığın DEPARTMENT(DNUMBER)
primary key’i, bu tabloya foreign key olarak eklenir.
Step 4:
Bu tablonun primary key’i,
Sahip varlığın primary key’i + zayıf varlığın partial Bir ER diyagramında iki varlık arasında 1:N ilişkisi
key’inden oluşur. varsa (örneğin bir departmanda birçok çalışan vardır),
bu durumda ilişki “çok” tarafında gösterilir.
DEPENDENT(ESSN, DEPENDENT_NAME, BIRTHDATE,
RELATIONSHIP) Adımlar:
PRIMARY KEY (ESSN, DEPENDENT_NAME) 1. “N tarafındaki” (çok tarafındaki) varlığı temsil
FOREIGN KEY (ESSN) REFERENCES EMPLOYEE(SSN) eden tabloyu bul.
(örneğin: EMPLOYEE çok taraf)
Step 3:
2. “1 tarafındaki” varlığın (örneğin
1. Yöntem: Foreign Key (2 tablo DEPARTMENT) birincil anahtarını (primary
kullanılarak) key),
“çok tarafındaki” tabloya foreign key (yabancı
Bir tablo (örneğin S) seçilir ve diğer tablonun
anahtar) olarak ekle.
(T) primary key’i, S tablosuna foreign key olarak
eklenir. 3. Eğer ilişkinin kendi basit nitelikleri (örneğin
Eğer ilişkiye tam katılım (total participation) gösteren tarih, ücret gibi) varsa,
bir varlık varsa, foreign key o varlık tablosuna bunları da çok tarafındaki tabloya ekle.
eklenmelidir.
Örnek:
Örnek:
MANAGES adlı 1:1 ilişkisinde, her DEPARTMENT bir İlişki: WORKS_FOR (EMPLOYEE → DEPARTMENT)
MANAGER tarafından yönetilir (ve her departmanın
 DEPARTMENT tablosunun primary key’i:
mutlaka bir yöneticisi vardır → total participation).
DNUMBER
  EMPLOYEE tablosuna eklenir: DNO (foreign DEPT_LOCATIONS(DNUMBER, DLOCATION)
key olarak)
Yani: Primary key: {DNUMBER, DLOCATION}

EMPLOYEE(SSN, FNAME, LNAME, ..., DNO) Step 7:

DEPARTMENT(DNUMBER, DNAME, MGR_SSN) Açıklama:

Step 5: Eğer ilişki 2’den fazla varlığı kapsıyorsa (örneğin

SUPPLY ilişkisi: Supplier, Part, Project),
Eğer iki varlık arasında çoktan çoka (M:N) bir ilişki bu durumda da yeni bir tablo oluşturulur.
varsa,
örneğin bir çalışan birçok projede çalışabilir, bir Adımlar:
projede de birçok çalışan olabilir, 1. Yeni bir ilişki tablosu (S) oluştur.
bu ilişkiyi göstermek için yeni bir tablo oluşturmak
gerekir. 2. İlişkiye katılan her varlığın primary key’ini
foreign key olarak ekle.
Adımlar:
3. Eğer ilişkinin kendi nitelikleri varsa, onları da
1. Yeni bir tablo (ilişki tablosu) oluştur. bu tabloya ekle.
Bu tablo, M:N ilişkiyi temsil eder.
4. Bu foreign key’lerin birleşimi primary key
2. Bu tabloya, ilişkideki her varlığın primary olur.
key’ini foreign key olarak ekle.
Örnek:
3. Bu foreign key’lerin birleşimi primary key
olur. İlişki: SUPPLY(SUPPLIER, PART, PROJECT)
Yeni tablo:
4. Eğer ilişkinin kendi nitelikleri varsa (örneğin
“çalışılan saat”), bunları da bu tabloya ekle. SUPPLY(SNAME, PARTNO, PROJNAME)

Örnek: Primary key: {SNAME, PARTNO, PROJNAME}

İlişki: WORKS_ON (EMPLOYEE – PROJECT)

Yeni tablo: WORKS_ON

EMPLOYEE’den SSN → ESSN (foreign key)

PROJECT’ten PNUMBER → PNO (foreign key)

Ekstra attribute: HOURS

Primary key: {ESSN, PNO}

WORKS_ON(ESSN, PNO, HOURS)

Step 6:

Açıklama:

Bir varlığın bir niteliği birden fazla değer alabiliyorsa,

bu multivalued attribute olur.
Örneğin bir departmanın birden fazla lokasyonu varsa
(LOCATIONS), bu çok değerli bir niteliktir.

Adımlar:

1. Her çok değerli nitelik için ayrı bir tablo

oluştur.

2. Bu tabloya:

O niteliğin kendisini (örneğin DLOCATION)

Ana varlığın primary key’ini (örneğin DNUMBER)

foreign key olarak ekle.

3. Bu iki alanın birleşimi primary key olur.

Örnek:

DEPARTMENT(DNUMBER, DNAME, MGR_SSN) Aşşağıda var bu üçlü ilişki

GENEL KONU TEKRARI

Meta-data table

Attribute türleri
Simple (Basit): Tek bir atomik değeri vardır.
Örnek: SSN, Cinsiyet.

Composite (Bileşik): Birden fazla alt bileşenden oluşur.

Örnek: Adres (Sokak, Şehir, Ülke), İsim (Ad, Soyad).

Multi-valued (Çok Değerli): Bir varlığın birden fazla değeri

olabilir.
Örnek: Arabanın renkleri, öğrencinin önceki diplomaları.

CARDINALITY

Her emplooyee en az 0 en çok 1 departmanı yönetir her

departmanı en az 1 en çok 1 employe yönetir şeklinde
[Link]ğer notasyona göre yazmak istesek böyle
gözükürdü.
UML DİYAGRAM

EER MODELLERİ

ÜNİVERSİTE DATABASEİ İÇİN CONCEPTUAL SCHEMA

 Çatalın uçları üstclassa bakar.

Bir altclassın birden fazla üstclassa sahip olması

Üstteki şekilde jobtype attributeu ekliyoruz onun değerine

göre alttaki subclasslara gidiyor.

COVERAGE

Disjoint, total ,Disjoint, partial ,Overlapping, total

Overlapping, partial

Üstteki dörtlüde disjoint üstclasstakilerin yalnızca bir

altclassa sahio olabileceğini gö[Link] Employee
sadece sekreter olabilir gibi Overlapping ise birden fazla
altclassa sahip olabileceğini söyler mesela bir employee
aynı anda hem engineer hem secretary olabilir gibi.

Total üst classta her nesnenin altclasslardan birine sahip

olması gerektiğini sö[Link] ise altclassa sahip
olmayabileceğini sö[Link] için her employee secretary
technician veya engineer olmak zorunda ama partial olursa
üçünden biri olmak zorunda değil.

Disjoint d overlapping o harfiyle gösterilir.

Total çift çizgi partial tek çizgi ile gösterilir.(Harf ve üstclass

arasındaki çizgi)
Union type burda birden fazla entitynin birleşerek üst class
oluşturmasıdı[Link] burda aracın sahibi banka şirket veya
şahıs olabilir bank ile arasında çift çizgi var muhtemelen
banka bilgisi her türlü olmalı galiba şahıs ve şirket bilgiside
olabilir yanında.

QUIZ 2 SORU CEVAPLARI

1)Discuss why we have the visual representations of

ONLY the tables DEPARTMENT, PROJECT, EMPLOYEE
and DEPENDENT in the initial design of E/R.

The initial E/R design includes only DEPARTMENT,

PROJECT, EMPLOYEE, and DEPENDENT because these
are the main entity types in the COMPANY database.

They represent the core objects the database needs to

model — the primary entities with independent existence
and their key attributes and relationships.

In the initial design, tables such as WORKS_ON or

DEPT_LOCATIONS were represented as multivalued
attributes to simplify the conceptual model.

2) (30 points) What about WORKS_ON and

DEPT_LOCATIONS tables in Figure-1? Why are these
tables not included in Figure-2?

Tables like WORKS_ON and DEPT_LOCATIONS, which

represent relationships between entities, are usually
omitted in the initial design stage:

 WORKS_ON connects EMPLOYEE and PROJECT

(many-to-many relationship).

 DEPT_LOCATIONS connects DEPARTMENT with

multiple LOCATIONS (one-to-many relationship).
These are not independent entities, but rather
associative relationships, so they are excluded
from the initial E/R diagram. They will appear later
when transforming the E/R model into relational
tables.

3) (20 points) What is the aim of the initial design in

E/R modeling?

The aim of the initial design in E/R modeling is to provide

a high-level conceptual representation of the data
requirements.7p
It identifies major entities and their attributes without
focusing on implementation or normalization details.7p
This stage helps ensure that the model correctly represents
the organization’s data semantics before proceeding to
logical or physical design.6p
 TÜRKÇESİ
Projede tasarlanacak veritabanı, Erasmus öğrenci değişim
programında farklı üniversite bölümlerinin müfredatlarını
karşılaştırmak ve eşleştirmek amacıyla yapılandırılacaktır.
Veritabanının temel veri gereksinimleri, üç ana varlık
üzerinden modellenebilir: Departments (Bölümler),
PROJENİN DATA Courses (Dersler) ve Semesters (Dönemler). Her
bölümün benzersiz bir DepartmentID ile tanımlanması
REQUİREMENTLARINI SORARSA
gerekir ve her bölüm birden fazla dersi içerebilir; bu nedenle
Department ile Course arasındaki ilişki bire-çok (1:N)
cardinality ile gösterilir. Her dersin CourseCode,
CourseName, ECTSCredits, SemesterOffered,
The database to be designed for this project will ShortDescription ve Prerequisites gibi temel
be structured to compare and integrate öznitelikleri bulunmalıdır. Önkoşullar, dersler arasındaki
curricula from different university departments hiyerarşik veya bağımlı yapıyı temsil etmek için Course ile
Course arasında öz-ilişki (self-relationship) ile 0:N
within the Erasmus student exchange program.
cardinality ile gösterilebilir.
The primary data requirements can be modeled
around three main entities: Departments, Her ders bir veya daha fazla dönemde sunulabilir; bu
bağlamda Semester entity’si eklenir ve her dönem birden
Courses, and Semesters. Each department
fazla dersi içerebilir, dolayısıyla Semester ile Course
should have a unique DepartmentID and can arasındaki ilişki de 1:N cardinality ile tanımlanır. Ayrıca,
include multiple courses; therefore, the Erasmus çerçevesinde farklı bölümler arasında ders
relationship between Department and eşdeğerlikleri önemli bir veri gereksinimidir. Bu amaçla,
CourseEquivalency gibi bir ilişki varlığı oluşturulabilir; bu
Course has a one-to-many (1:N)
varlık, farklı bölümlerdeki derslerin birbirine eşdeğerliğini
cardinality. Each course must include key gösterir ve her ders birden fazla eşdeğer derse sahip
attributes such as CourseCode, CourseName, olabileceğinden Course ile CourseEquivalency
ECTSCredits, SemesterOffered, arasındaki ilişki N:M cardinality ile modellenir. ECTS
kredileri ve ders içerikleri, eşdeğerliklerin
ShortDescription, and Prerequisites. değerlendirilmesinde kullanılır.
Prerequisites represent hierarchical or
dependent relationships among courses, and Son olarak, öğrenci bilgileri isteğe bağlı olarak entegre
edilebilir. Her öğrenci, belirli bir bölümde kayıtlıdır ve birden
can be modeled using a self-relationship on fazla ders seçebilir; dolayısıyla Student ile Course
Course with 0:N cardinality. arasında 1:N veya N:M ilişki, öğrencinin seçtiği dersleri
takip etmek için kullanılabilir. Bu veri gereksinimleri, hem
Each course may be offered in one or more her bölümün bağımsız müfredat yapısını hem de Erasmus
semesters; thus, a Semester entity is added, programı kapsamında ders eşdeğerliklerini doğru ve esnek
with each semester containing multiple courses, bir şekilde modellemek için yeterli olacak şekilde
tasarlanmıştır.
making the Semester-Course relationship
also one-to-many (1:N). Additionally, course NOT: ÇOK OKUMADIĞIM İÇİN TÜRKÇESİNİ DE ATTIM
equivalencies between different departments OKUYUP ONA GÖRE DÜZENLEYEBİLİRSİNİZ.ÜSTTEKİ
SAYFADA İŞİMİZE YARAYABİLECEK TÜM DATABASE
are an essential requirement in the Erasmus DESİGNLARINI ALDIM
context. A CourseEquivalency relationship
entity can be created to show which courses Pseudocode: Find Foreign Keys from
are equivalent across departments. Since a Known PK
course can have multiple equivalent courses,
Input: PK_Table (table name with known PK),
the relationship between Course and PK_Column (primary key column name)
CourseEquivalency has a many-to-many
(N:M) cardinality. ECTS credits and course Output: List of FKs referencing PK

content are used to evaluate these FK_List = []

equivalencies.
For each Table in Database:
Finally, student information can be optionally If Table != PK_Table:
integrated. Each student is enrolled in a specific
department and may take multiple courses, For each Column in Table:

resulting in a Student-Course relationship If [Link] == PK_Column.DataType:

that can be 1:N or N:M, depending on
If [Link] similar to PK_Column.Name
whether enrollment tracking or course selection OR check DBMS metadata:
is considered. These data requirements provide
a comprehensive structure to represent both Add ([Link]) to FK_List

the individual department curricula and course Return FK_List

equivalencies under the Erasmus program in a
flexible and accurate manner.
Step-by-Step Explanation Örnek: TotalCredits=SUM(ECTSCredits)
1. PK’yi tanımla: [Link] Domain: Alanın alabileceği değerler.
Örnek: Grade=0–100
2. Veritabanındaki diğer tabloları sırayla tara:
Application-Specific Constraints:
Enrollment, Grades, Attendance…
Uygulamaya özel kural. Örnek: Bir öğrenci
3. Her tablodaki sütunları PK ile karşılaştır: en fazla 5 ders alabilir
Veri tipi aynı mı? Referential Integrity: Tablolar arası
ilişkilerin tutarlılığı
İsmi benzer mi?
Relationships
DBMS metadata’da FK ilişkisi var mı?

4. PK’yi referans alan sütunları listele → bunlar Relationship: Entity’ler arası bağlantı.
FK olur. Örnek: Enrollment(Student, Course)
Role: Entity’nin relationship içindeki
5. Tüm tablolar tarandıktan sonra FK listesi
hazır. fonksiyonu. Örnek: Employee is
“Manager” in Manages
GENEL TERİMLER Weak Entity: Kendi başına benzersiz
olmayan entity. Örnek: Dependent →
Database Concepts Employee
Database: Düzenli veri koleksiyonu. Örnek: Higher Degree Relationship: 2’den fazla
Üniversite öğrenci ve ders bilgileri entity içeren ilişki. Örnek:
DBMS: Veritabanını yönetmek için yazılım. Project(Employee, Department, Client)
Örnek: MySQL, PostgreSQL
Schema: Veritabanının yapısı, tablolar ve
ilişkiler. Örnek: Student(StudentID, Name) ER & EER Concepts
Instance: Belirli zamandaki veritabanı
ER Diagram: Entity ve relationship
verisi. Örnek: Bugünkü kayıtlı öğrenciler
diyagramı
State: Veritabanının güncel durumu
EER: Gelişmiş ER modeli
Three-Schema Architecture: Internal
Subclass/Superclass: Alt ve üst entity tipi
(fiziksel), Conceptual (mantıksal), External
Specialization/Generalization: Alt sınıf
(kullanıcı görünümü)
oluşturma/üst sınıfa bağlama
Data Independence: Yapı değişse
Category/Union Types: Entity birden fazla
uygulama etkilenmez
üst türle bağlanabilir
Logical Independence: Mantıksal değişiklik
Attribute/Relationship Inheritance: Alt
uygulamayı etkilemez
entity üst entity’den özellik alır
Physical Independence: Fiziksel değişiklik
Constraints on
uygulamayı etkilemez
Specialization/Generalization: Kurallar
Entity & Attribute Ontology/Knowledge Representation:
Kavram ve ilişkilerin formel tanımı
Entity: Gerçek dünya nesnesi. Örnek:
Student, Course Design & Normalization
Attribute: Entity’nin özelliği. Örnek: Name,
Normalization: Tekrar ve tutarsızlığı
Age
azaltma (1NF, 2NF, 3NF)
Primary Key: Benzersiz tanımlayıcı. Örnek:
Denormalization: Performans için bilinçli
StudentID
veri tekrarı
Foreign Key: Tablolar arası ilişki. Örnek:
[Link] → [Link] Transactions & ACID
Unique: Tekrarlanan değer engeli. Örnek:
CourseCode Transaction: Veritabanı işlemi
Not Null: Boş değer olamaz Atomicity: İşlem tamamen başarılı veya
Check: Alan koşulunu kontrol eder. Örnek: başarısız
ECTSCredits 1–10 Consistency: Veri tutarlı kalmalı
Default: Varsayılan değer. Örnek: Isolation: İşlemler birbirini etkilemez
Semester=1 Durability: İşlem tamamlandıktan sonra
Composite Key: Birden fazla alan veri kalıcı
birleşerek benzersizlik sağlar. Örnek: DBMS Features
CourseID+Semester
Derived Attribute: Hesaplanan değer.
DDL: Tablo ve yapı tanımı
DML: Veri ekleme/silme/güncelleme
DCL: Yetkilendirme, izin
Index: Arama hızını artırır
Database Utilities: Yedekleme, geri
yükleme, veri taşıma

Architecture

Centralized: Tek sunucu

Client-Server: Sunucu-istemci ayrımı
Distributed: Veritabanı farklı sunuculara
dağılmış

Advantages / When Not to Use

Advantages: Veri bütünlüğü, güvenlik,

paylaşım, tutarlılık
When Not to Use: Çok küçük veri, basit
uygulamalar, yüksek maliyet

History

File Systems → Hierarchical → Network →

Relational → EER → Object-Relational →
NoSQL