Tablo ismi
son zamanlarda öğrenilen tekil doğrudur
Evet. Kafirlere dikkat edin. Tablo adlarındaki çoğul , standart materyallerin hiçbirini okumamış ve veritabanı teorisi hakkında bilgisi olmayan birinin kesin bir işaretidir.
Standartlar ile ilgili harika şeylerden bazıları:
- hepsi birbiriyle entegre
- Birlikte çalışıyorlar
- onlar bizimkinden daha büyük beyinler tarafından yazıldı, bu yüzden onları tartışmak zorunda değiliz.
Standart tablo adı , tablonun toplam içeriğini değil, tüm ayrıntıda kullanılan tablodaki her satırı ifade eder ( Customertablonun tüm Müşterileri içerdiğini biliyoruz ).
İlişki, Fiil İfade
Modellenmiş gerçek İlişkisel Veritabanlarında (1970 öncesi Kayıt Dosyalama Sistemlerinin aksine [ Record IDskolaylık sağlamak için bir SQL veritabanı kapsayıcısında uygulanan):
- tablolardır Denekler bu nedenle bunlar, veritabanının isimler , yine, tekil
- tablolar arasındaki ilişkiler vardır Eylemler dolayısıyla bunlar, isimler arasında gerçekleşecek fiiller (yani onlar keyfi numaralı veya adlandırılmış değildir)
- O ise Yüklem
- doğrudan veri modelinden okunabilen her şey (sonunda örneklerime bakın)
- (Bağımsız bir tablo için tahmin (bir hiyerarşide en üstteki üst öğe) bağımsız olması)
- bu nedenle Fiil İfadesi özenle seçilir, böylece en anlamlı ve genel terimlerden kaçınılır (bu deneyim ile daha kolay hale gelir). Fiil İfadesi modelleme sırasında önemlidir, çünkü modelin çözümlenmesine yardımcı olur, yani. ilişkileri açıklamak, hataları belirlemek ve tablo adlarını düzeltmek.
Diagram_A
Tabii ki, ilişki CONSTRAINT FOREIGN KEYalt tabloda bir SQL olarak uygulanır (daha sonra, daha sonra). İşte Fiil İfadesi (modelde), temsil ettiği Tahmin (modelden okunacak) ve FK Kısıtlama Adı :
Initiates
Each Customer Initiates 0-to-n SalesOrders
Customer_Initiates_SalesOrder_fk
Tablo • Dil
Bununla birlikte, tabloyu, özellikle Tahminler veya diğer belgeler gibi teknik dilde açıklarken , tek tek ve çoğulları doğal olarak İngilizce dilinde kullanın. Tablonun tek satır (ilişki) için adlandırıldığını ve dilin türetilmiş her satırı (türetilmiş ilişki) ifade ettiğini unutmayın:
Each Customer initiates zero-to-many SalesOrders
değil
Customers have zero-to-many SalesOrders
Yani, bir tablo "kullanıcı" var ve sonra sadece kullanıcının sahip olacağı ürünler var, tablo "kullanıcı-ürün" veya sadece "ürün" olarak adlandırılmalıdır? Bu bire çok ilişkidir.
(Bu bir adlandırma kuralı sorusu değildir; bu bir db tasarım sorusudur.) user::product1 :: n olması önemli değil . Önemli olan productayrı bir varlık olup olmadığı ve bağımsız tablo olup olmadığıdır . kendi başına var olabilir. Bu nedenle productdeğil user_product.
Ve eğer productsadece bir bağlamında varsa user, yani. bu nedenle Bağımlı bir Tabloduruser_product .
Diagram_B
Ve dahası, eğer her ürün için (bir sebepten dolayı) birkaç ürün tanımına sahip olsaydım, "kullanıcı-ürün-açıklaması" ya da "ürün-açıklaması" ya da sadece "açıklaması" olur mu? Tabii ki doğru yabancı tuşları ile .. Ben de kullanıcı açıklaması veya hesap açıklaması ya da her neyse olabilir çünkü sadece açıklama Adlandırma sorunlu olacaktır.
Doğru. Yukarıdakilere göre ya user_product_descriptionxor product_descriptiondoğru olacaktır. Onu diğerinden ayırt etmek değil xxxx_descriptions, ama isme ait olduğu yere bir anlam vermek için önek üst tablodur.
Sadece iki sütunlu saf bir ilişkisel tablo (çoktan çoğa) istersem ne olur? "user-stuff" veya "rel-user-stuff" gibi bir şey? Ve birincisi, bunu "kullanıcı ürünü" nden ayıracak olursa?
Umarım ilişkisel veritabanındaki tüm tablolar saf ilişkisel, normalleştirilmiş tablolardır. Bunu adda tanımlamaya gerek yoktur (aksi takdirde tüm tablolar olacaktır rel_something).
Yalnızca iki ebeveynin PK'larını içeriyorsa ( mantıksal düzeyde varlık olarak var olmayan mantıksal n :: n ilişkisini fiziksel bir tabloya çözümleyen), bu İlişkisel Tablo'dur . Evet, genellikle ad iki üst tablo adının birleşimidir.
Fiil İfadesi'nin çocuk tablosunu görmezden geldiği için ebeveynten ebeveyne uygulandığı ve okunduğu gibi okunduğuna dikkat edin, çünkü hayattaki tek amacı iki ebeveyni ilişkilendirmektir.
Diagram_C
Eğer durum bu ise olmayan bir ilişkisel Tablosu (yani., İki PKler ek olarak, bu veri içeren), daha sonra uygun bir şekilde adı ve fiil İfadeler ilişki sonunda, bunun için üst uygulanır.
Diagram_D
İki user_producttablo ile sonuçlanırsanız , bu, verileri normalleştirmediğinizin çok yüksek bir sinyalidir. Bu yüzden birkaç adım geri gidin ve bunu yapın ve tabloları doğru ve tutarlı bir şekilde adlandırın. İsimler daha sonra kendiliğinden çözülecektir.
Adlandırma kuralı
Herhangi bir yardım son derece takdir ve çocuklar tavsiye orada adlandırma kongre standardı bir tür varsa, bağlantı kurmaktan çekinmeyin.
Yaptığınız şey çok önemlidir ve her düzeyde kullanım ve anlayış kolaylığını etkileyecektir. Bu yüzden başlangıçta mümkün olduğunca fazla anlayış elde etmek iyidir. SQL'de kodlamaya başlamadan önce, bunların çoğunun alaka düzeyi net olmayacaktır.
Vaka , adreslenen ilk öğedir. Tüm büyük harfler kabul edilemez. Özellikle tablolara kullanıcılar tarafından doğrudan erişilebiliyorsa karışık durum normaldir. Veri modellerime bakın. Arayan, sadece küçük harflere sahip bazı demanslı NonSQL kullanıyorsa, bunu veririm, bu durumda alt çizgileri eklerim (örneklerinize göre).
Uygulama veya kullanım odağını değil, veri odağını koruyun . Sonuçta, 2011'den sonra 1984'ten beri Açık Mimari'ye sahibiz ve veritabanlarının bunları kullanan uygulamalardan bağımsız olması gerekiyor.
Bu şekilde, büyüdükçe ve birden fazla uygulama bunları kullandığından, adlandırma anlamlı kalacaktır ve düzeltmeye gerek yoktur. (Tek bir uygulamaya tamamen katıştırılmış veritabanları veritabanı değildir.) Veri öğelerini yalnızca veri olarak adlandırın.
Çok dikkatli olun ve tabloları ve sütunları çok doğru bir şekilde adlandırın . Kullanmayın UpdatedDateeğer bu bir DATETIMEveri türü, kullanım UpdatedDtm. _descriptionDoz içeriyorsa kullanmayın .
Veritabanında tutarlı olmak önemlidir . Kullanmayın NumProductÜrün sayısını ve göstermek için tek bir yerde ItemNoveya ItemNumöğe sayısını belirtmek için başka bir yerde. Kullanım NumSomethingsayılar-of ve için SomethingNoveya SomethingIdsürekli olarak, tanımlayıcılar için.
Sütun adının önüne tablo adı veya kısa kod yazmayın user_first_name. SQL zaten niteleyici olarak tablename sağlar:
table_name.column_name -- notice the dot
İstisnalar:
İlk istisna PK'lar içindir, özel işlemlere ihtiyaç duyarlar, çünkü onları her zaman birleşimler halinde kodlarsınız ve anahtarların veri sütunlarından öne çıkmasını istersiniz. Her zaman kullan user_id, asla id.
- Bu olduğuna dikkat olmayan bir ön ek olarak kullanılan bir tablo adını, ama anahtar bileşeni için uygun bir açıklayıcı adı:
user_idkolon olduğunu belirler, bir kullanıcı değil, idbir usertablo.
- (Tabii ki dosyalara suretlerle erişildiği ve ilişkisel anahtarların olmadığı kayıt dosyalama sistemleri hariç, bunlar bir ve aynı şeydir).
- PK'nın FK olarak taşındığı (taşındığı) her zaman anahtar sütun için tam olarak aynı adı kullanın.
- Bu nedenle
user_producttablonun user_idPK'sinin bir bileşeni olacaktır (user_id, product_no).
- kodlamaya başladığınızda bunun önemi anlaşılacaktır. Birincisi, bir
idçok tablo ile SQL kodlamasında karıştırılması kolaydır. İkincisi, ilk kodlayıcının ne yapmaya çalıştığı hakkında hiçbir fikri olmayan herkes. Anahtar sütunlar yukarıdaki gibi ele alınırsa, her ikisinin de önlenmesi kolaydır.
İkinci istisna, alt öğede taşınan aynı ana tablo tablosuna başvuran birden fazla FK'nin bulunduğu durumdur. İlişkisel Model uyarınca, anlamı veya kullanımı ayırt etmek için Rol Adlarını kullanın, örn. AssemblyCodeve ComponentCodeiki kişilik PartCodes. Ve bu durumda, do not farklılaşmamış kullanmak PartCodeonlardan biri için. Kesin ol.
Diagram_E
Önek
100'den fazla tablonuz varsa, tablo adlarına Konu Alanı önekini ekleyin :
REF_
OE_Sipariş Girişi kümesi vb. için referans tabloları için
Sadece fiziksel seviyede, mantıksal değil (modeli tıkar).
Sonek
Tablolarda asla sonek kullanmayın ve her zaman her zaman sonek kullanın. Bu, veritabanının mantıksal ve normal kullanımında alt çizgi olmadığı anlamına gelir; ancak idari tarafta, alt çizgiler ayırıcı olarak kullanılır:
_VGörünüm (ana ile TableNametabii ki, önünde)
_fkYabancı Key (kısıtlama adı değil, sütun adı)
_cacÖnbellek
_segSegmenti
_trİşlem (saklı yordam veya işlev)
_fn(işlemsel olmayan) Fonksiyonu, vb
Biçim, tablo veya FK adı, alt çizgi ve işlem adı, alt çizgi ve son olarak sonektir.
Bu gerçekten önemlidir, çünkü sunucu size bir hata mesajı verdiğinde:
____blah blah blah error on object_name
tam olarak hangi nesnenin ihlal edildiğini ve ne yapmaya çalıştığını biliyorsunuz:
____blah blah blah error on Customer_Add_tr
Yabancı Anahtarlar (sütun değil, kısıtlama). Bir FK için en iyi adlandırma Fiil İfadesini kullanmaktır (eksi "her" ve kardinalite).
Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk
Kullanım Parent_Child_fkdiziyi değil, Child_Parent_fksen onları ve (b) her zaman biz hangi ebeveyn olduğu tahmin ederek ne, çocuk parmağı olduğunu aradığında, (a) doğru sıralama düzeninde gösterir çünkü. Hata mesajı daha sonra keyifli olur:
____ Foreign key violation on Vendor_Offers_PartVendor_fk.
Bu, Fiil İfadelerinin tespit edildiği verilerini modellemekle uğraşan insanlar için iyi çalışır. Geri kalanı için, kayıt dosyalama sistemleri, vb Parent_Child_fk.
Onlar bir isimlendirme oluşan çok kendi kuralını, başlangıçtan bugüne Endeksler, özeldir sırayla , 1 ila 3 den her karakter pozisyonu:
UBenzersiz veya _benzersiz olmayan
CKümelenmiş veya _kümelenmemiş
_ayırıcı için
Geri kalanlar için:
Tablo adının dizin adında gerekli olmadığını unutmayın , çünkü her zaman aşağıdaki gibi görünürtable_name.index_name.
Yani ne zaman Customer.UC_CustomerIdveya Product.U__AKbir hata mesajı görünür, size anlamlı bir şeyler anlatır. Bir tablodaki indekslere baktığınızda, bunları kolayca ayırt edebilirsiniz.
Kalifiye ve profesyonel birini bulun ve takip edin. Tasarımlarına bakın ve kullandıkları adlandırma kurallarını dikkatlice inceleyin. Anlamadığınız herhangi bir şey hakkında onlara özel sorular sorun. Tersine, kurallara veya standartlara ad verme konusunda çok az saygı gösteren herkesten cehennem gibi çalıştırın. İşte başlamanız için birkaç örnek:
- Yukarıdakilerin hepsinin gerçek örneklerini içerirler. Bu konudaki soruları yeniden adlandırarak sorular sorun.
- Elbette, modeller , sözleşmeleri adlandırmanın ötesinde, başka birçok Standart uygular ; şimdilik bunları görmezden gelebilir veya yeni sorular sormaktan çekinmeyin .
- Her biri birkaç sayfadır, Stack Overflow'daki satır içi görüntü desteği kuşlar içindir ve farklı tarayıcılara sürekli yüklenmez; bağlantıları tıklamanız gerekecek.
- PDF dosyalarında tam gezinme olduğunu unutmayın, bu nedenle mavi cam düğmelere veya genişletmenin tanımlandığı nesnelere tıklayın:
- İlişkisel Modelleme Standardına aşina olmayan okuyucular IDEF1X Notasyonu yararlı bulabilir .
Standart Uyumlu Adreslerle Sipariş Girişi ve Envanter
PHP / MyNonSQL için ofisler arası Bülten sistemi
Tam Temporal kapasiteye sahip Sensör İzleme
Soruların Yanıtları
Bu yorum alanında makul bir şekilde cevaplanamaz.
Larry Lustig:
... en önemsiz örnek bile gösteriyor ...
Bir Müşterinin Sıfırdan Fazla Ürüne ve Bir Ürünün birden çok Bileşene ve Bileşenin Birden Çok Tedarikçiye sahip olması ve bir Tedarikçinin sıfır satması -Çok sayıda Bileşen ve SalesRep'in bir-çok Müşterisi vardır Müşteriler, Ürünler, Bileşenler ve Tedarikçileri tutan tabloların "doğal" adları nedir?
Yorumunuzda iki büyük sorun var:
Örneğinizi "en önemsiz" olarak ilan edersiniz, ancak bundan başka bir şey değildir. Bu tür bir çelişki ile, ciddi olup olmadığınıza, teknik olarak yetenekli olup olmadığınıza emin değilim.
Bu "önemsiz" spekülasyonda birkaç brüt Normalizasyon (DB Tasarımı) hatası vardır.
Bunları düzeltene kadar, doğal olmayan ve anormaldirler ve herhangi bir anlam ifade etmezler. Bunları anormal_1, anormal_2 vb. Olarak adlandırabilirsiniz.
Hiçbir şey sağlamayan "tedarikçileriniz" var; dairesel referanslar (yasadışı ve gereksiz); herhangi bir ticari enstrümanı olmayan ürünleri (Fatura veya SalesOrder gibi) satın alma esası olarak satın alan müşteriler (veya müşterilerin "kendi" ürünleri?); çözülmemiş çoktan çoğa ilişkiler; vb.
Bu, Normalize edildiğinde ve gerekli tablolar belirlendikten sonra, adları açık hale gelecektir. Doğal olarak.
Her durumda, sorgunuza hizmet vermeye çalışacağım. Bu, ne demek istediğinizi bilmeden bir anlam katmam gerekeceği anlamına gelir, bu yüzden lütfen bana katlanın. Brüt hatalar listelemek için çok fazla ve yedek spesifikasyon verildiğinde, hepsini düzelttiğimden emin değilim.
Ürün bileşenlerden oluşuyorsa, ürünün bir montaj olduğunu ve bileşenlerin birden fazla montajda kullanıldığını varsayacağım.
Yaptıkları, "Tedarikçi sıfır-çok Bileşenleri satar" Bundan başka, değil satmak ürün veya montajlar, sadece bileşenleri satmak.
Spekülasyon vs Normalize Model
Farkında değilseniz, kare köşeler (Bağımsız) ve yuvarlak köşeler (Bağımlı) arasındaki fark önemlidir, lütfen IDEF1X Gösterim bağlantısına bakın. Aynı şekilde düz çizgiler (Tanımlama) ile kesikli çizgiler (Tanımlamayan).
... Müşteriler, Ürünler, Bileşenler ve Tedarikçileri tutan tabloların "doğal" adları nelerdir?
- Müşteri
- Ürün
- Bileşen (Veya AssemblyComponent, bir gerçeğin diğerini tanımladığını fark edenler için)
- Tedarikçi
Artık tabloları çözdüğüme göre, sorununuzu anlamıyorum. Belki belirli bir soru gönderebilirsiniz .
VoteCoffee:
Ronnis'in 2 tablo (user_likes_product, user_bought_product) arasında birden fazla ilişkinin olduğu örneğinde yayınladığı senaryoyu nasıl ele alıyorsunuz? Yanlış anlayabilirim, ancak bu, ayrıntılı olarak belirttiğiniz kuralı kullanarak yinelenen tablo adlarına neden görünüyor.
Normalizasyon hatası olmadığını varsayarsak User likes Product, tablo değil, yüklemdir. Onları karıştırmayın. Konuya, Fiillere ve Tahminlere ilişkin cevabım ve hemen yukarıdaki Larry'ye cevabım.
Her tablo bir dizi Gerçek içerir (her satır bir Olgudur). Tahminler (veya önermeler), Gerçek değildir, doğru olabilir veya olmayabilir.
İlişkisel Model (daha yaygın Birinci Dereceden Mantık olarak da bilinir) Birinci Derece yüklemler mantığında dayanmaktadır. Bir Tahmin, doğru veya yanlış olarak değerlendirilen basit, kesin İngilizce'de tek cümlelik bir cümledir.
Ayrıca, her tablo bir değil , birçok Öngörüyü temsil eder veya uygular .
Sorgu, doğru (Gerçek var) veya yanlış (Gerçek yok) ile sonuçlanan bir Tahmin (veya birlikte zincirlenmiş bir dizi Tahmin) testidir.
Bu nedenle tablolar, cevabımda (adlandırma kuralları) ayrıntılı olarak belirtildiği gibi, satır, Gerçek ve Tahminler için belgelenmelidir (elbette, veritabanı belgelerinin bir parçasıdır), ancak ayrı bir Öngörüler listesi olarak belirtilmelidir. .
Bu önemli olmadıklarına dair bir öneri değildir. Çok önemli, ama buraya yazmam.
Çabuk, o zaman. Yana İlişkisel Model FOPC üzerine kurulmuştur, tüm veritabanı FOPC bildirimleri bir dizi, yüklemler bir dizi olduğu söylenebilir. Ancak (a) birçok tahmin türü vardır ve (b) bir tablo bir Predicate'i temsil etmez ( birçok Predicate'in ve farklı Predicate türlerinin fiziksel uygulamasıdır ).
Bu nedenle tabloyu "" temsil ettiğini tahmin "olarak adlandırmak saçma bir kavramdır.
"Teorisyenler" sadece birkaç Öngörünün farkındadırlar, RM'nin FOL üzerine kurulduğundan beri , tüm veritabanının bir dizi Öngörme ve farklı türde olduğunu anlamıyorlar .
Ve elbette, tanıdıkları az sayıda insandan saçma olanları seçerler EXISTING_PERSON:; PERSON_IS_CALLED. Çok üzücü olmasaydı komik olurdu.
Ayrıca, Standart veya atom tablosu adının (satırı adlandırarak) tüm sözlü ayrıntılar için mükemmel bir şekilde çalıştığını unutmayın (tabloya eklenen tüm Tahminler dahil). Tersine, aptal "tablo yüklemi temsil eder" adı olamaz. Tahminler hakkında çok az şey anlayan, ancak aksi halde geciktiren "teorisyenler" için iyidir.
Veri modeline alakalı Predicates, ifade edilir de modelde, iki siparişlerin vardır.
Unary Predicate
İlk set metin değil , diyagramatiktir : gösterimin kendisi . Bunlar arasında çeşitli Varoluşçu; Kısıtlama odaklı; ve Tanımlayıcı (öznitelikler) Tahmin eder.
- Tabii ki, bu sadece bir Standart veri modelini 'okuyabilen' bu Tahminleri okuyabileceği anlamına gelir. Bu nedenle, salt metin zihniyetleri tarafından ciddi şekilde sakatlanan "teorisyenler", veri modellerini okuyamaz, neden 1984 öncesi salt metin zihniyetlerine sadık kalırlar.
İkili Tahmin
İkinci küme Gerçekler arasındaki ilişkileri oluşturan kümedir. Bu ilişki çizgisidir. (Yukarıda belirtilmiştir) bir fiil kalıbı doğrulama'yı tanımlar önerme (terimi ile test edilebilir) uygulanmıştır. Kişi bundan daha açık olamaz.
- Bu nedenle, Standart veri modelleri bilmektedir birine, bütün Predicates alakalı , modelde belgelenmiştir. Ayrı bir Öngörüler listesine ihtiyaç duymazlar (ancak her şeyi veri modelinden 'okuyamayan' kullanıcılar yapar!).
Tahminleri listelediğim bir Veri Modeli . Bu örneği seçtim, çünkü Varoluşçu vb. Tahminleri ve İlişkiyi gösterdikleri için, listelenmeyen tek Tahminler Tanımlayıcılardır. Burada, arayıcının öğrenme seviyesi nedeniyle, ona kullanıcı olarak davranıyorum.
Bu nedenle, iki üst tablo arasında birden fazla alt tablonun olması sorun değildir, bunları yalnızca Varoluşçu İçerik olarak adlandırın ve adları normalleştirin.
İlişkisel Tablolar için ilişki adları için Fiil İfadeleri için verdiğim kurallar burada devreye girer. Özet olarak, belirtilen tüm noktaları kapsayan bir Predicate ve Table tartışması.
İyi bir kısa açıklama için Öngörülerin doğru kullanımı ve bunların nasıl kullanılacağı (buradaki yorumlara yanıt verme ile oldukça farklı bir bağlam), bu cevabı ziyaret edin ve Öngörme bölümüne gidin.
Charles Burns:
Diziye göre, bir kurala göre bir sayıyı ve bir sonrakini (örn. "Ekle 1") saklamak için kullanılan Oracle tarzı nesneyi kastetmiştim. Oracle'ın otomatik kimlik tablolarından yoksun olması nedeniyle tipik kullanımım, tablo PK'ları için benzersiz kimlikler oluşturmaktır. Foo (id, somedata) DEĞERLERİNE EKLE (foo_s.nextval, "veri" ...)
Tamam, buna Anahtar veya NextKey tablosu diyoruz. Bu şekilde adlandırın. SubjectAreas'ınız varsa, veritabanında yaygın olduğunu belirtmek için COM_NextKey kullanın.
Btw, bu anahtarları üretmek için çok zayıf bir yöntem. Hiç ölçeklenemez, ancak Oracle'ın performansı ile muhtemelen "gayet iyi". Ayrıca, veritabanınızın bu alanlarda ilişkisel değil, vekillerle dolu olduğunu gösterir. Bu da son derece zayıf performans ve bütünlük eksikliği anlamına gelir.
primarily opinion-based, açıkça yanlıştır.