Bir uygulamanın veriye ihtiyacı olduğunu söylemek kolaydır. Asıl soru, hangi verinin nasıl organize edileceğidir.
Bir CRM uygulamasında müşteriler nerede tutulacak? Bir görev yönetim sisteminde çalışanlarla görevler nasıl ilişkilendirilecek? Bir stok uygulamasında ürün hareketleri nasıl takip edilecek? Bir müşteriyle yapılan görüşme, ilgili çalışan ve görevle nasıl bağlantılı hale getirilecek?
Clomosy Cloud Tables, geliştiricilere yalnızca bulutta veri saklama imkânı sunmak yerine farklı iş senaryolarında kullanılabilecek hazır veri yapıları sağlar.
Cloud Tables içerisinde Groups, Customers, Employees, Items, Products, TTypes, Tasks, Activities, ThreadMasters, Threads, ThreadDetails ve MemberGroups gibi birbirleriyle ilişkilendirilebilen yapılar bulunur.
Bu yazıda tabloların teknik alanlarını tek tek sıralamak yerine, ne amaçla kullanılabileceklerini ve gerçek bir iş uygulamasında nasıl bir araya gelebileceklerini inceleyeceğiz.
Cloud Tables Mantığı Nasıl Çalışıyor?
Cloud Tables yapısındaki tabloların büyük bölümünde benzersiz bir GUID alanı bulunur.
Örneğin:
- Customer →
Customer_GUID - Employee →
Employee_GUID - Product →
Product_GUID - Task →
Task_GUID - Activity →
Activity_GUID - Thread →
Thread_GUID
Yeni bir kayıt oluşturulduğunda ID ve GUID değerleri bulut sistemi tarafından oluşturulur. Geliştiricinin create veya update işlemlerinde identity ID alanlarını göndermesi gerekmez.
Yeni kayıt oluştururken GUID boş bırakılır. Var olan bir kaydı güncellerken ilgili kaydın GUID değeri kullanılır. Silme işlemleri ise fiziksel silme yerine Rec_Deleted = 1 kullanılarak soft-delete mantığıyla gerçekleştirilir.
Bu sayede geliştirici Clomosy'nin entegre bulut fonksiyonları üzerinden CRUD operasyonlarını gerçekleştirebilir ve daha sonra kullanacağı kayıtların GUID değerlerini saklayabilir.
Şimdi bu yapının içerisindeki tabloların gerçek projelerde ne ifade ettiğine bakalım.
Groups: Verileri Organize Etmenin Temeli
TBLProjectGroups, Cloud Tables yapısının önemli merkezlerinden biridir.
Groups tablosunu basitçe bir gruplama veya klasör sistemi olarak düşünebiliriz.
Customers, Employees, Items, Products, Tasks ve Activities gibi birçok tablo kendi Group alanı üzerinden Groups yapısıyla ilişkilendirilebilir.
Gerçek Hayat Örneği: Departman Bazlı Organizasyon
Bir şirket içi yönetim uygulaması geliştirdiğimizi düşünelim.
Şirket içerisinde:
Satış
Teknik Destek
Finans
Operasyon
gibi farklı gruplar oluşturulabilir.
Çalışanlar ilgili gruplarla, görevler de kendi operasyonel gruplarıyla ilişkilendirilebilir.
Groups içerisinde OwnerGroup_ID alanının bulunması, gerektiğinde üst-alt grup mantığının kurulmasına da imkân verir.
Örneğin:
Satış
→ Kurumsal Satış
→ Bireysel Satış
gibi hiyerarşik organizasyonlar oluşturulabilir.
Bu nedenle Groups yalnızca bir kategori tablosu değil, farklı Cloud Tables kayıtlarını organize etmek için kullanılabilecek ortak bir yapı olarak düşünülebilir.
Customers: Müşteri ve İletişim Yönetimi
TBLProjectCustomers, müşteri veya iletişim kayıtlarının tutulması için hazırlanmıştır.
Tabloda müşterinin adı ve kodunun yanında ad, soyad, doğum tarihi, şehir, adres, e-posta ve mobil telefon gibi alanlar bulunur.
Ayrıca debit ve credit amount alanları sayesinde müşteriyle ilişkili sayısal finansal değerlerin tutulabileceği alanlar da mevcuttur.
Gerçek Hayat Örneği: CRM Uygulaması
Bir satış ekibi için CRM uygulaması geliştirdiğinizi düşünün.
Yeni bir potansiyel müşteri geldiğinde Customers içerisine kayıt oluşturulabilir:
Müşteri: ABC Teknoloji
Yetkili: Mehmet Yılmaz
Şehir: İstanbul
E-posta: ilgili iletişim adresi
Grup: Kurumsal Müşteriler
Ancak müşteri kaydını oluşturmak tek başına yeterli değildir.
Müşteriyle yapılan görüşmeleri, toplantıları veya takip işlemlerini kaydetmek istediğimizde Customers yapısını Activities ve Threads ile birlikte kullanabiliriz.
Böylece müşteri yalnızca bir iletişim kartı olmaktan çıkar ve uygulamadaki operasyonel süreçlerin bir parçası haline gelir.
Employees: Çalışan ve Atama Yönetimi
TBLProjectEmployees, çalışan veya işlem atanabilecek kişi kayıtlarının tutulması için kullanılabilir.
Employees içerisinde ad, soyad, e-posta, telefon, adres ve şehir gibi temel bilgilerin yanında Group ilişkisi de bulunur.
Daha önemlisi, Tasks ve Activities tabloları Employee kayıtlarıyla ilişkilendirilebilir.
Gerçek Hayat Örneği: Teknik Servis Ekibi
Bir teknik servis uygulaması düşünelim.
Sistemde üç çalışanımız olsun:
Ayşe → Teknik Destek
Can → Saha Ekibi
Deniz → Müşteri İlişkileri
Yeni bir teknik problem geldiğinde ilgili işlem için Task oluşturulabilir ve görev belirli bir Employee kaydına atanabilir.
Böylece uygulama:
“Görev nedir?”
sorusunun yanında:
“Bu görevden kim sorumlu?”
sorusunun da cevabını veri yapısında tutabilir.
Items: Genel Amaçlı Kayıt Kataloğu
TBLProjectItems, Cloud Tables içerisindeki daha genel amaçlı yapılardan biridir.
Items; kod, isim, durum, grup, kategori ve alt kategori gibi temel alanlardan oluşur.
Products kadar fiyat ve stok odaklı değildir. Bu nedenle parasal veya stok özelliklerine ihtiyaç duyulmayan genel varlıkları temsil etmek için değerlendirilebilir.
Gerçek Hayat Örneği: Ekipman Takibi
Bir şirketin iç operasyon uygulamasını düşünelim.
Items içerisinde:
Toplantı Odası Projektörü
Depo Terminali
Şirket Aracı 01
Ofis Yazıcısı
gibi kayıtlar tutulabilir.
Bu kayıtlar Groups ile organize edilebilir ve gerektiğinde Threads aracılığıyla başka işlemlerle ilişkilendirilebilir.
Örneğin şirket aracına ilişkin bir olay veya kayıt oluşturulduğunda ilgili Item, Thread üzerinden bu işlemle bağlantılı hale getirilebilir.
Products: Ürün, Fiyat ve Stok Yönetimi
TBLProjectProducts, Items'a kıyasla ticari ürün senaryolarına yönelik daha zengin alanlara sahiptir.
Ürün adı ve açıklamasının yanında birden fazla fiyat alanı, miktar ve adet bazında giriş-çıkış değerleri, bakiye, KDV ve birim bilgileri tutulabilir.
Gerçek Hayat Örneği: Restoran Yönetim Sistemi
Bir restoran uygulamasında Products içerisinde:
Margherita Pizza
Cheeseburger
Filtre Kahve
Limonata
gibi ürünler tutulabilir.
Her ürün için fiyat bilgileri tanımlanabilir ve ürünler farklı Groups altında organize edilebilir.
Örneğin:
Yiyecekler
→ Pizzalar
→ Burgerler
İçecekler
→ Sıcak İçecekler
→ Soğuk İçecekler
Ürün hareketleri gerektiğinde Threads üzerinden Product ile ilişkilendirilebilir. Thread içerisindeki quantity, piece, price, discount, amount ve VAT alanları bu tür işlem senaryolarının modellenebilmesine yardımcı olur.
Tasks: Yapılacak İşleri Yönetmek
TBLProjectTasks, belirli bir çalışana atanabilen iş kayıtları için hazırlanmıştır.
Her Task için isim, açıklama, durum, öncelik, oluşturulma tarihi, bitiş tarihi ve tamamlanma tarihi gibi bilgiler tutulabilir.
Task için atanmış Employee alanı zorunlu bir ilişkidir.
Gerçek Hayat Örneği: Yazılım Ekibi
Bir yazılım şirketinin iç proje yönetim uygulamasını düşünelim.
Bir görev şöyle olabilir:
Görev: Mobil giriş ekranını güncelle
Çalışan: Ahmet
Öncelik: Yüksek
Durum: Devam Ediyor
Son Tarih: 25 Eylül
Başka bir görev ise:
Görev: Yeni müşteri raporunu hazırla
Çalışan: Selin
Durum: Bekliyor
şeklinde tutulabilir.
Böylece Clomosy Cloud Tables üzerinde basit bir yapılacaklar listesinden daha kapsamlı bir ekip görev yönetim sistemine kadar farklı yapılar geliştirilebilir.
Activities: İş Sürecinde Gerçekleşen Aktiviteler
Tasks “ne yapılması gerekiyor?” sorusuna odaklanırken Activities, gerçekleşen veya planlanan aktivitelerin modellenmesi için kullanılabilir.
Bir Activity aynı anda Customer, Employee ve Task kayıtlarıyla ilişkilendirilebilir.
Bu özellik Activities tablosunu özellikle CRM ve operasyon uygulamalarında kullanışlı hale getirir.
Gerçek Hayat Örneği: Satış Görüşmesi
Bir CRM sisteminde şöyle bir Task olduğunu düşünelim:
ABC Teknoloji teklif sürecini takip et.
Bu görev satış temsilcisi Ayşe'ye atanmış olsun.
Müşteriyle telefon görüşmesi gerçekleştirildiğinde Activity oluşturulabilir:
Activity: Teklif sonrası müşteri görüşmesi
Customer: ABC Teknoloji
Employee: Ayşe
Task: Teklif sürecini takip et
Durum: Tamamlandı
Böylece müşteri, çalışan, görev ve gerçekleşen aktivite aynı iş sürecinin farklı parçaları olarak ilişkilendirilebilir.
TTypes: Thread Türlerini Tanımlamak
TBLProjectTTypes, Thread kayıtlarının türlerini tanımlamak için kullanılan lookup yapısıdır.
Örneğin uygulamanın ihtiyacına göre:
Satış
Görüşme
Not
Stok Hareketi
Destek Kaydı
gibi Thread türleri oluşturulabilir.
Bu sayede Threads içerisinde farklı amaçlara hizmet eden kayıtların hangi türde olduğu ayrıştırılabilir.
Threads: Farklı Verileri Birbirine Bağlayan İşlem Katmanı
Cloud Tables yapısındaki en esnek tablolardan biri TBLProjectThreads tablosudur.
Threads; Activity, Customer, Employee, Group, Item, Product, Task, ThreadMaster ve TType gibi farklı kayıtlarla ilişkilendirilebilir.
Ayrıca tarih, miktar, adet, fiyat, indirim, tutar ve farklı value alanlarını taşıyabilir.
Bu nedenle Thread yapısını bir işlem veya olay kaydı olarak düşünmek mümkündür.
Gerçek Hayat Örneği: Müşteri Satış İşlemi
Bir satış uygulamasında elimizde şu kayıtların olduğunu düşünelim:
Customer: ABC Market
Employee: Ayşe Yılmaz
Product: Ürün A
Task: Siparişi hazırla
TType: Satış
Yeni bir Thread oluşturularak bu kayıtların tamamı aynı işlem içerisinde ilişkilendirilebilir.
Örneğin Thread:
İşlem: ABC Market Ürün A Satışı
Müşteri: ABC Market
Çalışan: Ayşe Yılmaz
Ürün: Ürün A
Görev: Siparişi hazırla
Miktar: 10
Fiyat: 250
Tür: Satış
gibi bir iş sürecini temsil edebilir.
Buradaki önemli teknik ayrıntı, Threads üzerinde ilişkili kayıtları yazarken ilgili ID değerlerinin değil GUID değerlerinin kullanılmasıdır.
Örneğin bir Item bağlanacaksa Thread_Item_ID göndermek yerine ilgili Item kaydının Item_GUID değeri Thread_Item_GUID olarak gönderilir.
Clomosy Cloud sistemi GUID'i çözümler ve ilgili ID bağlantısını veritabanında oluşturur.
Aynı yaklaşım Customer, Employee, Product, Task, Activity, Group, ThreadMaster ve TType ilişkileri için de geçerlidir.
ThreadMasters: Birden Fazla İşlemi Tek Belgede Toplamak
TBLProjectThreadMasters, bir grup Thread kaydı için üst belge veya header yapısı olarak kullanılabilir.
Master içerisinde belge numarası, belge tarihi, açıklama, not, adres, e-posta, telefon, tutar ve farklı değer alanları bulunur.
Gerçek Hayat Örneği: Sipariş Belgesi
Bir müşterinin tek siparişte üç farklı ürün aldığını düşünelim.
Sipariş #10025
altında:
Thread 1 → Ürün A × 5
Thread 2 → Ürün B × 2
Thread 3 → Ürün C × 10
gibi bir yapı kurulabilir.
ThreadMaster burada siparişin genel belgesini, Threads ise bu belgeyle ilişkili işlemleri temsil edebilir.
Bu yapı sipariş, işlem belgesi veya benzeri çok satırlı iş süreçlerinin modellenmesinde değerlendirilebilir.
ThreadDetails: Bir İşlemin Alt Detayları
TBLProjectThreadDetails, bir Thread kaydının altında daha detaylı satırlar oluşturmak için kullanılabilir.
Her Detail kaydı zorunlu olarak bir Thread ile ilişkilidir.
Detail içerisinde miktar, fiyat, tutar, sıra, durum ve farklı value alanları bulunur.
Gerçek Hayat Örneği: Servis İşlemi
Bir teknik servis Thread'i düşünelim:
Thread: Laptop Bakım İşlemi
Bunun altında ThreadDetails ile:
1. Batarya kontrolü
2. SSD testi
3. Fan temizliği
4. Sistem kontrolü
gibi alt kayıtlar oluşturulabilir.
Böylece tek bir işlem kendi içerisinde daha küçük detaylara ayrılabilir.
MemberGroups: Üye ve Grup İlişkileri
TBLProjectMemberGroups, üyelerin Groups ile ilişkilendirilmesi için kullanılan yapıdır.
Diğer ana tablolardan farklı olarak GUID alanı bulunmaz. Bu tablonun anahtarı Member_ID değeridir.
Ayrıca string, text, float, integer ve date türlerinde farklı değer alanları bulunur.
Bu yapı bir üyenin belirli bir grup içerisindeki bağlantısını veya gruba bağlı ek değerlerini tutmak için kullanılabilir.
Gerçek Bir İş Uygulamasında Tablolar Nasıl Birlikte Çalışır?
Şimdi tüm yapıyı gerçek bir senaryo üzerinden birleştirelim.
Bir teknik servis ve müşteri yönetim uygulaması geliştirdiğimizi düşünelim.
Müşteri cihazıyla ilgili destek talebi oluşturuyor.
1. Customers
Müşterinin iletişim bilgileri Customers içerisinde tutulur.
Customer: Ahmet Yılmaz
2. Items
Servise gelen cihaz Items içerisinde tanımlanabilir.
Item: Ahmet Yılmaz - Laptop
3. Employees
Servis işlemini gerçekleştirecek teknisyen Employees içerisinde bulunur.
Employee: Mehmet Kaya
4. Tasks
Teknisyene yapılacak iş atanır.
Task: Laptop arızasını incele
5. Activities
Müşteriyle gerçekleştirilen görüşme Activity olarak tutulabilir.
Activity: İlk teknik destek görüşmesi
Bu Activity müşteri, çalışan ve ilgili Task ile ilişkilendirilebilir.
6. TTypes
İşlem türü tanımlanabilir.
TType: Teknik Servis
7. ThreadMaster
Servis işleminin genel belgesi oluşturulabilir.
Master: SRV-2026-00125
8. Threads
Müşteri, cihaz, çalışan, görev, aktivite, işlem türü ve Master kaydı bir Thread içerisinde birbirine bağlanabilir.
Thread böylece:
“Ahmet Yılmaz'ın laptopu için Mehmet Kaya tarafından yürütülen teknik servis işlemi”
gibi bir iş olayını veri tarafında temsil edebilir.
9. ThreadDetails
Yapılan kontroller ise ThreadDetails içerisinde tutulabilir:
Batarya kontrol edildi
SSD testi gerçekleştirildi
Fan temizlendi
İşletim sistemi kontrol edildi
Sonuçta birbirinden bağımsız tablolar yerine aynı operasyonu farklı açılardan temsil eden ilişkili bir veri modeli ortaya çıkar.
Bir Başka Senaryo: Satış ve CRM Uygulaması
Aynı Cloud Tables yapısı tamamen farklı bir projede de kullanılabilir.
Örneğin satış ekibi için geliştirilen bir CRM uygulamasında:
Groups → Satış ekipleri ve müşteri grupları
Customers → Potansiyel ve mevcut müşteriler
Employees → Satış temsilcileri
Products → Satılan ürünler
Tasks → “Teklif hazırla”, “Müşteriyi ara” gibi görevler
Activities → Telefon görüşmeleri, toplantılar ve takip aktiviteleri
TTypes → Satış, görüşme, teklif gibi işlem türleri
ThreadMasters → Sipariş veya üst işlem belgeleri
Threads → Müşteri, çalışan, ürün ve görevleri birbirine bağlayan işlemler
ThreadDetails → İşlemin alt detayları
olarak kullanılabilir.
Aynı veri altyapısı farklı iş modellerine uyarlanabilir.
Bir Başka Senaryo: Restoran Operasyon Uygulaması
Cloud Tables yalnızca CRM veya kurumsal görev sistemleri için düşünülmek zorunda değildir.
Bir restoran uygulamasında:
Groups → Menü kategorileri veya operasyon grupları
Products → Yiyecek ve içecekler
Employees → Çalışanlar
Customers → Kayıtlı müşteriler
Tasks → Hazırlanması veya tamamlanması gereken operasyonel işler
Activities → Müşteri veya çalışanlarla ilişkili aktiviteler
TTypes → Sipariş, işlem veya diğer uygulama tarafından tanımlanan hareket türleri
ThreadMasters → Birden fazla işlemi bir araya getiren üst kayıtlar
Threads → Ürün, müşteri, çalışan ve diğer kayıtlarla ilişkilendirilebilen işlem satırları
ThreadDetails → Thread altındaki ek detaylar
şeklinde bir yapı kurulabilir.
Buradaki temel avantaj, geliştiricinin her yeni uygulamada veri modeline tamamen boş bir sayfadan başlamak zorunda kalmamasıdır.
Hazır Tablolar Neden Önemli?
Cloud tabanlı bir uygulama geliştirirken yalnızca veritabanı oluşturmak yeterli değildir.
Verilerin nasıl organize edileceği, hangi tabloların birbirleriyle ilişkilendirileceği ve daha sonra sistem büyüdüğünde yapının nasıl genişletileceği de düşünülmelidir.
Clomosy Cloud Tables bu noktada geliştiricilere gerçek çalışma ortamlarında test edilmiş ve kullanılan hazır tablo yapıları sunar.
Böylece bir geliştirici:
“Müşteri tablosunu nasıl tasarlamalıyım?”
sorusundan başlayıp tüm veri altyapısını sıfırdan oluşturmak yerine hazır Customers yapısını kullanabilir.
Benzer şekilde görevler için Tasks, çalışanlar için Employees, ürünler için Products ve farklı kayıtları aynı iş sürecinde bir araya getirmek için Threads kullanılabilir.
API Katmanından Uygulama Mantığına
Cloud Tables yaklaşımının önemli taraflarından biri de bu veri yapılarının Clomosy'nin kendi bulut fonksiyonlarıyla entegre olmasıdır.
Geliştiriciler ayrı bir API bağlantısı kurmadan Cloud Tables üzerinde CRUD işlemleri gerçekleştirebilir.
Bu yaklaşım geliştiricinin odağını:
“Veritabanına nasıl bağlanacağım?”
sorusundan:
“Uygulamam bu verilerle ne yapacak?”
sorusuna taşıyabilir.
Özellikle hızlı prototipleme, mobil iş uygulamaları, CRM sistemleri, görev yönetimi, stok ve operasyon uygulamalarında bu yaklaşım geliştirme sürecinin daha merkezi yönetilmesine yardımcı olabilir.
Sonuç: Tablolar Değil, Birbirine Bağlı İş Süreçleri
Clomosy Cloud Tables'a yalnızca hazır veritabanı tabloları olarak bakmak yapının kullanım alanını eksik anlatır.
Asıl değer, tabloların birlikte kullanılabilmesinde ortaya çıkar.
Customers müşteriyi, Employees çalışanı, Products ürünü, Tasks yapılacak işi ve Activities gerçekleşen aktiviteleri temsil edebilir.
Groups kayıtları organize ederken TTypes işlemlerin türlerini tanımlayabilir.
Threads ise farklı kayıtları aynı işlem veya olay etrafında birbirine bağlayabilir. ThreadMasters ve ThreadDetails kullanılarak bu işlemler daha kapsamlı üst belge ve alt detay yapılarına dönüştürülebilir.
Sonuçta geliştirici sıfırdan ayrı bir veri modeli ve API katmanı oluşturmak yerine, Clomosy'nin bulut altyapısındaki hazır yapıları kullanarak kendi iş mantığına odaklanabilir.
Bir CRM'den teknik servis uygulamasına, restoran operasyonundan ekip görev yönetimine kadar farklı projelerde aynı temel veri ekosistemi farklı şekillerde değerlendirilebilir.
Cloud Tables'ın yaklaşımı tam olarak burada ortaya çıkıyor:
Hazır tablolarla başla, ilişkileri kur ve kendi iş sürecini oluştur.
Sık Sorulan Sorular
Clomosy Cloud Tables hangi tabloları içerir?
Cloud Tables yapısında Groups, Customers, Employees, Items, MemberGroups, Products, TTypes, Tasks, Activities, ThreadMasters, Threads ve ThreadDetails gibi farklı amaçlara yönelik tablolar bulunmaktadır.
Items ile Products arasındaki fark nedir?
Items daha genel amaçlı kayıtları temsil edebilecek temel alanlara sahiptir. Products ise açıklama, birden fazla fiyat, miktar, adet, KDV ve birim gibi ürün ve stok senaryolarına yönelik daha kapsamlı alanlar içerir.
Tasks ile Activities arasındaki fark nedir?
Tasks, bir çalışana atanması gereken işleri temsil etmek için kullanılabilir. Activities ise müşteri, çalışan ve görevlerle ilişkilendirilebilen planlanan veya gerçekleşen aktivitelerin tutulmasına olanak sağlar.
Threads ne işe yarar?
Threads, Customer, Employee, Product, Item, Task, Activity, Group, TType ve ThreadMaster gibi farklı kayıtları aynı işlem veya olay içerisinde ilişkilendirebilen merkezi bir yapıdır.
Thread ilişkileri nasıl oluşturulur?
Thread oluştururken veya güncellerken ilişkili kayıtların ID değerleri yerine ilgili GUID değerleri gönderilir. Örneğin bir ürün bağlantısı için Thread_Product_GUID alanına ürünün Product_GUID değeri gönderilir. Clomosy Cloud sistemi bu GUID'i ilgili ID değerine çözümler.
Kayıtların ID değerlerini geliştirici mi oluşturur?
Hayır. Identity ID alanları veritabanı tarafından oluşturulur. Create veya update işlemlerinde bu ID alanları gönderilmez.
Cloud Tables üzerinde kayıt nasıl silinir?
Cloud Tables soft-delete yaklaşımını kullanır. İlgili kaydın GUID değeriyle birlikte Rec_Deleted = 1 gönderilerek kayıt silinmiş olarak işaretlenir. MemberGroups tablosunda GUID bulunmadığı için anahtar olarak Member_ID kullanılır.
Cloud Tables ile CRM geliştirilebilir mi?
Tablo yapıları Customers, Employees, Tasks, Activities, Products ve Threads gibi CRM senaryolarında kullanılabilecek alanlar ve ilişkiler içerir. Bunların uygulama içerisinde nasıl kullanılacağı geliştirilen projenin iş mantığına göre belirlenebilir.
Cloud Tables sadece kurumsal uygulamalar için mi kullanılabilir?
Hayır. Hazır yapılar teknik servis, CRM, görev yönetimi, ürün yönetimi, restoran operasyonu ve benzeri farklı veri odaklı uygulama senaryolarına uyarlanabilir.
