Google Sheet'ten ilişkisel şemaya geçiş, basit adımlarla: tekrar eden grupları bulun, anahtarları seçin, ilişkileri eşleyin ve ilerideki veri karmaşasını önleyin.
Bir e-tablo küçük bir liste için harikadır. Sütunları anında değiştirebilir, her yere not ekleyebilir ve gözle sorunları düzeltebilirsiniz. Bu özgürlük, dosya ortak bir doğruluk kaynağı olduğunda bozulmaya başlar.
Veri büyüdükçe aynı sorunlar tekrar tekrar ortaya çıkar. Müşteri veya ürünü saklayacak tek bir yer olmadığında kopyalar görürsünüz. Aynı şey hakkında iki satır farklı değer içerdiğinde çelişkiler çıkar, örneğin telefon numarası. Filtreleme ve raporlama sinir bozucu olur çünkü bazı sütunlar listeler gizler ("Etiketler", "Ürünler", "Katılımcılar") veya formatları karıştırır ("$1,200", "1200", "1.2k").
Google Sheet'ten ilişkisel bir şemaya geçmek güvenlikle ilgilidir. Bir veritabanı daha net bir yapı zorlar, böylece çelişkiler yaratmadan sorgulayabilir, doğrulayabilir ve güncelleyebilirsiniz.
Faydalı bir zihinsel model: bir satır bir gerçek nesneyi temsil etmelidir. Bir satır bir fırsatı, bir müşteriyi ve bir ürün listesini temsil ediyorsa, bunlardan herhangi birini daha sonra güncellemek acı verir.
Kısa bir test: tek bir satırın aynı alan için iki değere ihtiyacı oluyor mu?
Cevap evet ise, bu "geniş satır" sorunu değil. Bu "ayrı tablo" sorunu. Bir kez temiz modellediğinizde, kırılgan manuel düzenlemelere güvenmek yerine üstüne formlar ve doğrulama kurabilirsiniz.
Bir e-tablo düzenli görünebilir ama farklı insanlar için farklı şeyler ifade edebilir. Google Sheet'i ilişkisel bir şemaya dönüştürmeden önce, sayfanın neyi takip ettiğinde anlaşın.
Sütunlarla değil sonuçlarla başlayın. Verinin hangi kararları desteklemesi gerekiyor: haftalık gelir raporu, gecikmiş ticket listesi, takip atan bir iş akışı ya da müşteri görüşmesi sırasında hızlı arama? Bir kararı isimlendiremiyorsanız, o alan genellikle veritabanında olmamalıdır.
Sonra başlıklarda ve notlarda saklanan isimleri çıkarın. Bunlar genellikle gelecekteki tablolarınızdır: müşteriler, siparişler, ürünler, faturalar, ticketlar, temsilciler, lokasyonlar. Bir sütun iki ismi karıştırıyorsa (örneğin “Müşteri + Şirket”), birden çok şeyi aynı yerde saklıyorsunuz demektir.
Anlamdaki küçük farklar sonra büyük temizliklere dönüşür. Temel konularda net olun:
Örnek: sayfanızda her "Sipariş" için bir satır varsa ama "Ürünler" hücresi virgülle ayrılmış bir liste içeriyorsa, o satırın bir ödeme işlemini, bir sevkiyatı mı yoksa bir faturayı mı temsil ettiğine karar verin. Her seçim farklı bir şemaya götürür.
Orijinal sayfanın bir kopyasını salt okunur olarak dondurun. Yeni tabloların hâlâ aynı soruları cevapladığını doğrulamak için onu kullanacaksınız.
Google Sheet'ten ilişkisel bir şemaya dönüştürmeden önce sayfanın veri gibi görünmesini sağlayın, rapor gibi değil. Veritabanları tutarlı satır ve sütunlara ihtiyaç duyar. Dekoratif düzenler modellemeniz gereken desenleri saklar.
Birleştirilmiş hücreler, çoklu başlık satırları ve veri aralığı içindeki ara toplamlar gibi düzen numaralarını kaldırın. Bir başlık satırı tutun ve sonra sadece kayıt satırları olsun. Toplamlara ihtiyacınız varsa, bunları gerçek kayıtlara karışmasın diye ayrı bir özet sekmesine koyun.
Ardından her sütunda formatları tutarlı hale getirin. Bir veritabanı "1/2/24", "2024-02-01" ve "Feb 1"'in aynı tarih olduğunu tahmin edemez. Aynı şey telefon numaraları, para birimi ve isimler için de geçerlidir. Bir format seçin ve her yerde kullanın, katı gelse bile.
Kısa bir temizlik turu genelde işe yarar:
Son olarak, içinde birden çok değer olan hücreleri (ör. "kırmızı, mavi, yeşil") işaretleyin. Hemen şemayı düzeltmeyin. Sadece bu sütunların daha sonra ayrı satırlara dönüşeceğini hatırlamak için işaretleyin.
E-tablo veri modellemesindeki en büyük uyarı işareti tekrarlamadır. Tablolar sıklıkla "birden fazla şeyi" tek bir satırda sıkıştırmak için sütunları tekrar eder veya bir hücreye birden çok değer koyar. Bu, hızlı izleme için işe yarar, sonra filtreleme, raporlama veya tutarlı güncellemeler gerektiğinde bozulur.
Aşağıdaki biçimleri tarayın:
Item 1, Item 2, Item 3 veya Phone 1, Phone 2 gibi numaralandırılmış sütunlar.Örnek: satış takipçiniz Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2 kullanıyorsa duvara çarpacaksınız. Bazı siparişler 1 ürün, bazıları 8 ürün içerir. Sayfa ya sonsuza kadar yana doğru büyür ya da veri kaybetmeye başlar. İlişkisel modelde "Orders" tek bir tablo olur, ve "Order Items" her siparişteki ürüne karşılık gelen ayrı satırlardan oluşan başka bir tablo olur.
"Hücredeki listeler" için her değeri kendi kaydı olarak düşünün. "Email, SMS" yazan bir hücre genellikle kanalların temiz takip edilmesi için ayrı bir tablo (veya join tablosu) gerektirir.
Karışık sütunlar sessizdir ama aynı derecede risklidir. Erken bölün ki her alan tek bir gerçek olguyu saklasın.
Sayfadaki gerçek dünya şeylerini isimlendirebildiğinizde, her birini kendi tablosuna dönüştürün. E-tablosu tek bir büyük ızgara olmaktan çıkar ve daha küçük, amaçlı listelere dönüşür.
Bir satır iki farklı şey hakkında ayrıntı karıştırıyorsa, muhtemelen iki tabloya ihtiyaç vardır. Bir satış takip satırı müşteri bilgisi (isim, telefon), sipariş bilgisi (tarih, durum) ve ürün bilgisi (SKU, fiyat) içerebilir. Müşteriler her sipariş değiştiğinde değişmez ve ürünler tek bir siparişe bağlı değildir. Bunları ayırmak kopya düzenlemeleri ve uyumsuz değerleri önler.
Her şeyi kesinleştirmeden önce her tablo için bir cümlelik amaç yazın. Bir tabloyu "ve ayrıca" diyerek tanımlayamıyorsanız genelde çok geniştir.
Pratik bazı kurallar:
Sonra sütunlara açık ve tutarlı isimler verin. Basit isimler tercih edin ve "Info" veya "Details" gibi belirsiz etiketlerden kaçının.
Her tablo için erken birincil anahtar seçin. İyi bir anahtar sıkıcıdır: asla değişmez, her zaman vardır ve bir satırı yalnızca bir satırla tanımlar.
Doğal anahtarlar (gerçek dünya değerleri) işe yarayabilir, ama sadece gerçekten sabitlerse. SKU genellikle iyi bir doğal anahtardır çünkü kalıcı olması amaçlanmıştır. E-posta adresleri sabitmiş gibi görünür ama insanlar e-postalarını değiştirir, posta kutularını paylaşır ve "john@" ile "john.work@" gibi çoğaltmalar yaratabilir. İsimler, telefon numaraları ve adresler değişir ve benzersiz olmaları garanti değildir.
Güvenli bir varsayılan otomatik oluşturulan ID'dir (ör. customer_id, order_id). Doğal tanımlayıcıyı normal bir alan olarak tutun ve iş kurallarınıza uyuyorsa benzersizlik kuralı ekleyin. Bir e-posta değişse bile customer_id aynı kalır ve ilişkili siparişler doğru müşteriye işaret etmeye devam eder.
Basit anahtar kuralları:
Örnek: Contacts tablosunda birincil anahtar olarak contact_id kullanın. email alanını yalnızca iş kuralınız bir iletişim = bir e-posta ise benzersiz yapın. Herkesin telefon paylaşmadığını düşünerek phone boş olabilir.
Çoğu hata şeylerin nasıl ilişkili olduğunu tahmin etmekten gelir. Basit bir kural kullanın: eğer bir satır birçok şeyi "sahipleniyorsa" bu bire-çoktur. Yabancı anahtarı "çok" tarafına koyun.
Örnek: bir Customer birçok Order'a sahip olabilir. Orders tablosu customer_id tutmalı. Müşteriler içinde virgülle ayrılmış sipariş numaraları tutarsanız, kopyalar ve eksik veriler hızla ortaya çıkar.
Çoktan-çoğa, e-tablo tuzaklarından biridir. Bir Order birçok Product içerebiliyor ve bir Product birçok Order'da görünebiliyorsa join tablosu gerekir (genellikle line items). Bu tablo genelde order_id, product_id ve miktar ile satın alma anındaki fiyat gibi alanları içerir.
Bire-bir ilişkiler nadirdir. Ek verinin opsiyonel olduğu veya gizlilik/performance için ayrı tutulduğu durumlarda anlamlıdır (ör. User ve UserProfile). İki sekme olduğu için bir tabloyu ayırdıysanız bu uyarı işaretidir.
Geçmişin kendi yapısı olmalıdır. Değerler zamanla değişebiliyorsa (durum, fiyat, adres), tek bir sütunu üzerine yazmaktan kaçının. Değişiklikleri bir geçmiş tablosunda satırlar olarak saklayın ki "o tarihte ne doğruydu?" sorusuna cevap verebilesiniz.
Basit kural: bir gerçeği bir yerde saklayın. Bir müşterinin telefon numarası beş satırda görünüyorsa, biri dörtünü günceller ve beşinciyi kaçırır.
Normalizasyon basit terimlerle:
Birinci normal form (1NF) her hücrenin tek bir değer tutması demektir. Bir sütun "kırmızı, mavi, yeşil" veya "SKU1|SKU2|SKU3" içeriyorsa bu gizli bir listedir. İlişkili bir tabloda satırlara bölün.
İkinci normal form (2NF) çoğunlukla sipariş öğelerinde görünür. Eğer OrderItems anahtarı (OrderID, ProductID) ise CustomerName gibi alanlar oraya ait değildir. Onlar siparişe bağlıdır, ürüne değil.
Üçüncü normal form (3NF) anahtar olmayan alanların diğer anahtar olmayan alanlara bağlı olmamasını söyler. Örnek: ZipCode ve City depolanıyorsa ve City ZipCode ile belirleniyorsa uyumsuzluk riski vardır.
Hızlı bir kendi kendine kontrol:
Okuma ağırlıklı raporlama için denormalize etmek kabul edilebilir, ama bunu güvenli yapın: rapor tablosunu yeniden oluşturulabilir bir kopya olarak kabul edin. Normalleştirilmiş tabloları gerçek doğruluk kaynağı olarak tutun.
Hesaplanmış değerler için (toplamlar, bakiyeler, durum) çoğaltmayın; yeniden hesaplama kuralınız yoksa kopyalamayın. Pratik yaklaşım: ham işlemleri saklayın, sorgularda toplamları hesaplayın ve performans gerekliyse toplamları cache'leyin.
Çoğu "sayfada işe yaradı" problemi araçlardan değil anlamdan gelir. Amaç her satırın bir net şeyi, her seferinde aynı şekilde söylemesini sağlamaktır.
Yaygın tuzaklar:
Eğer Orders tablonuzda Item 1, Item 2, Item 3 gibi sütunlar varsa, bir tekrarlayan grup görüyorsunuz. Orders tablosu artı OrderItems tablosu planlayın.
Şemayı kilitlemeden önce son bir netlik turu yapın. Daha sonra oluşacak veritabanı sıkıntılarının çoğu erken alınan küçük kısa yolların sonucudur.
Sorgulayın: her tablo basit bir soruyu cevaplıyor mu? "Customers" tablosu müşterileri mi ifade ediyor, yoksa müşteriler artı son siparişleri artı çağrı notlarını mı? Bir tabloyu kısa bir cümleyle tanımlayamıyorsanız, karışık demektir.
Son kontroller:
Gerçek dünya testi: aynı müşteriyi hafif farklı yazımla iki kez giren birinin hayal edin. Eğer şemanız bunu kolay hale getiriyorsa, daha iyi bir anahtar veya benzersizlik kuralı ekleyin.
Her satır bir anlaşma olan bir satış takipçisi hayal edin. Sütunlar Müşteri Adı, Müşteri E-posta, Anlaşma Tutarı, Aşama, Kapanış Tarihi, Ürünler (virgülle ayrılmış liste) ve Notlar (bazen bir hücrede birden çok not) içeriyor.
O tek satır iki tekrar eden grubu gizler: ürünler (bir anlaşma birden çok ürün içerebilir) ve notlar (bir anlaşmanın birçok notu olabilir). Dönüşümlerin sıkça yanlış gittiği yer burasıdır çünkü hücre içi listeler sorgulamayı zorlaştırır ve çelişkiler yaratır.
İşin nasıl davrandığına uyan temiz bir "sonrası" modeli:
CustomerId, DealId ve ProductId stabil tanımlayıcılardır. DealProducts çoktan-çoğa ilişkiyi çözer: bir anlaşma birçok ürün içerebilir ve bir ürün birçok anlaşmada görünebilir. DealNotes notları ayrı tutar, böylece "Not 1, Not 2, Not 3" sütunlarına sahip olmazsınız.
Modellemeden önce bir rapor olan "ürüne göre gelir" gibi sorgular, dizeleri parçalamayı ve insanların isimleri tutarlı yazmasını ummayı gerektirirdi. Modelden sonra, DealProducts ile Deals ve Products'ı joinleyerek doğrudan sorgulanabilir hale gelir.
Şemanız kağıt üzerinde doğru görünüyorsa, gerçek bir veritabanına taşıyıp gerçek verilerle test edin. Her şeyi bir kerede içe aktarmayın. Önce küçük bir parti yükleyin, çöken yerleri düzeltin, sonra devam edin.
Riskleri düşük tutan pratik sıra:
Karmaşık e-tablo alışkanlıklarının geri gelmemesi için doğrulama kurallarını erken ekleyin. Zorunlu alanları gerçekten zorunlu yapın, izin verilen değerleri sınırlayın (örneğin durum), formatları doğrulayın (tarihler ve e-postalar) ve yabancı anahtarlar kullanarak var olmayan bir müşteri için sipariş yaratılamamasını sağlayın.
Sonra sayfayı güncelleme için kullanmayı bırakın. İnsanlara basit formlar ve net iş akışları sunduğunuzda verilerin korunması çok daha kolay hale gelir.
Eğer şemayı kod yazmadan çalışan iç araca dönüştürmek istiyorsanız AppMaster (appmaster.io) yardımcı olabilir: tabloları ve ilişkileri görsel olarak modelleyin, sonra aynı modelden üretime hazır bir backend, web uygulaması ve native mobil uygulamalar üretin.
Ne zaman Google Sheet kullanmayı bırakıp ilişkisel şemaya geçmeliyim?Tablo paylaşılan bir doğruluk kaynağı gibi davranıyor ve çoğaltmalar, çelişkili değerler veya raporlamada zorluklar görüyorsanız geçin. Virgülle ayrılmış listeler, Item 1/Item 2 sütunları veya sürekli kopyala/yapıştır düzeltmeleriyle uğraşıyorsanız ilişkisek bir şema zaman kazandırır.
Bir şeyin ayrı bir tablo olması gerektiğini nasıl anlarım?Bir satır aynı alandan birden çok değere ihtiyaç duyuyorsa yineleyen bir gruba sahipsiniz demektir. Örnekler: bir siparişte birden çok ürün, bir müşterinin birden fazla adresi veya bir etkinliğin birden çok katılımcısı. Bunlar çocuk tablolar (veya join tablolar) olmalıdır; ekstra sütunlar ya da hücre içi listeler değil.
Tabloları tasarlamadan önce ne temizliği yapmalıyım?Orijinal sayfanın salt okunur bir kopyasını dondurun, sonra birleştirilmiş hücreleri, birden çok başlık satırını ve veri aralığındaki ara toplam satırlarını çıkarın. Her sütunu tutarlı hale getirin (tek bir tarih formatı, tek bir para birimi formatı, boşları temsil etme kuralı) ki gerçek yapı görünür olsun.
Birincil anahtar olarak e-posta/isim mi yoksa ID mi kullanmalıyım?Varsayılan olarak her tablo için otomatik oluşturulan bir ID kullanın; bu, insanlar e-posta, ad veya telefon güncellediğinde bile sabit kalır. Gerçek dünya tanımlayıcılarını (e-posta, SKU) normal alan olarak bırakın ve yalnızca işiniz için kopyalar gerçekten yanlışsa benzersizlik kuralı ekleyin.
Bire-çok ile çoktan-çoğa ilişkileri nasıl modellemeliyim?Sahiplik kuralına göre eşleyin: bir müşteri birden çok siparişe sahipse, customer_id Orders tablosunda olmalı. Eğer ilişki çoktan çoğa ise (siparişler ve ürünler gibi), order_id, product_id ve miktar gibi alanları içeren bir join tablosu (ör. OrderItems) ekleyin.
Bu dönüşümde “yeterince normalleştirmek” ne demek?Çünkü çelişkileri önler. Bir gerçeği tek bir yerde saklamak, onu bir kez güncellemenizi ve diğerlerinin tutarlı kalmasını sağlar. Mükemmel normalizasyon gerekmez ama aynı müşteri telefonunun birçok satırda dağılmasını engelleyecek kadar normalleştirin.
Virgülle ayrılmış listelerle (etiketler, ürünler, katılımcılar) ne yapmalıyım?Her değeri ayrı bir satır yapın. "Email, SMS" gibi bir hücre filtrelemeyi ve doğrulamayı zorlaştırır. Her seçimi ana satıra bağlanan ayrı bir kayıt olarak saklayan ilişkili bir tablo (veya join tablosu) oluşturun.
Durum veya fiyat gibi zamanla değişen alanları nasıl yönetmeliyim?“Mevcut durum”u ve “geçmiş”i ayırın. Zaman önemliyse durum değişikliklerini zaman damgasıyla olay/işlem satırları olarak saklayın. Bu, “geçen ay durum neydi?” gibi soruları doğru yanıtlamanızı sağlar.
Veriyi kırmadan güvenle taşımanın en güvenli yolu nedir?İlk olarak küçük bir parti (yaklaşık 50–200 satır) içe aktarın, toplamları ve bazı kayıtları donmuş sayfa ile karşılaştırın. Haritalama hatalarını, eksik ID'leri ve tekrarları düzeltin, sonra yeniden içe aktarın. Süreç tekrarlanabilir ve öngörülebilir olunca tüm veriyi yükleyin.
Şemayı kod yazmadan iç araç haline getirebilir miyim?Kod yazmadan, şema formlar, doğrulamalar ve iş akışları içeren çalışan bir uygulamaya dönüşsün istiyorsanız no-code araçlar yardımcı olabilir. AppMaster (appmaster.io) ile tabloları ve ilişkileri görsel olarak modelleyip aynı modelden üretime hazır bir backend, web uygulaması ve native mobil uygulamalar oluşturabilirsiniz.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
