Bunun gibi 4 tablo var (bu bir örnek):

Company:
ID
Name
CNPJ

Department:
ID
Name
Code
ID_Company 

Classification:
ID
Name
Code
ID_Company

Workers:
Id 
Name
Code
ID_Classification
ID_Department

Bir olduğunu varsayalım classificationile id = 20, id_company = 1. Ve departmentbu id_company = 2(başka bir şirketi temsil eder).

Bu, sınıflandırma ve departman şirkete ayrı ayrı bağlandığından, iki şirketten bir işçinin yaratılmasına izin verecektir. Bunun olmasını istemiyorum, bu yüzden ilişkilerimle ilgili bir sorunum var ve nasıl çözüleceğini bilmiyorum.

Sorununuz, modelinizde bir varlık türü eksik olmasından kaynaklanıyor. Aşağıdaki ERD'yi düşünün:

Bir ekledik unutmayın kesişme varlık türünü arasında DEPARTMENTve CLASSIFICATION. Bu yeni varlık türü: POSITIONmodelinizde örtük olan, belirli bir departmanın çeşitli sınıflandırmalardan oluşan bir dizi işi olduğu bilgisini sağlar.

POSITIONModelinizi açık bir varlık olarak eklemenin birkaç avantajı vardır.

1. WORKERPotansiyel olarak farklı şirketlerin departmanlarına ve sınıflandırmalara atanmasıyla ilgili endişenizi önler .
2. Maaş notu gibi bir pozisyon için geçerli olabilecek diğer tahminler için size bir konum sunar.
3. WORKERŞu anda pozisyonda hiç pozisyon olmasa bile, bir pozisyonun var olduğu gerçeğini kaydetmenize izin verir , bu da oldukça yararlı bilgilerdir.

Bir departman için tanımlanmış bir pozisyon sorunu ve farklı şirketlerde bulunan bir sınıflandırma probleminden kaçınmak için, her ikisinin de anahtarlarını genişlettim DEPARTMENTve CLASSIFICATIONbu, Todd Everett'in cevabında uzun süre okuyabileceğiniz nedenler için iyi.

DİKKAT Yukarıdaki model basitleştirmeyi öngörmektedir. Özellikle, her pozisyonun sadece bir kez kaydedildiğini varsayar. Bu, iş kurallarınıza uygun olabilir veya olmayabilir. POSITIONBir şirket içinde aynı departman ve sınıflandırma için birden fazla kayda ihtiyacınız varsa, bir yedek anahtar girebilirsiniz POSITION.

İlişkilerle ilgili bir sorununuz olduğunu düşünmüyorum. Bunun yerine sorun her tablo için yedek anahtarlar (yani Ids) kullanarak elde edilen veritabanı Sınıflandırma başka bir Bölüm iken bir Bölümü olan İşçilerin eklenmesini engelleyemez ve tersi olduğunu düşünüyorum. Bunu anlamanın iyi bir yolu şemayı bir ER Diyagramı aracı kullanarak görselleştirmektir. Ben kullanacağı Oracle Data Modeler ücretsiz olarak indirilebilir aracı.

ER Şeması

Haliyle, 2 şirketiniz olabilir - deyin IBMve Microsoft. IBMbir Software Developmentdepartman olabilir ve Microsoft bir Desktop Softwaredepartman olabilir. IBM'in bir Software Engineersınıflandırması olabilir ve Microsoft'un bir Software Developersınıflandırması olabilir. Şimdi, çünkü sizin için bir yedek anahtarınız var Departmentve Classificationbu Software Developmentbir IBMdepartman ve Desktop Softwarebir Microsoftdepartman olması, gelecekteki çocuk ilişkileri için kayboluyor. Bu da böyledir Classification. Bu nedenle , departmanında Harlan Millsbir IBMçalışan olan, Software Developmentsınıflandırması Software DeveloperbirMicrosoftsınıflandırma! Aynı şekilde, işçiye doğru sınıflandırma ve yanlış departman verilebilir! İlk örneği gösteren bir diyagram:

1 Ids temsil eder IBMve 2 Ids temsil eder Microsoft. Ben kırmızı senaryoda vurguladığınız nerede Harlan Millsve Bill Gatestersi 200 sınıflandırma kimliği ve yardımcısı ilişkili 10 bölüm Id tarafından canlandırıldığı yanlış bölümler, atanır.

Çözülecek Seçenekler

Peki onun olmasını önlemek için seçenekler nelerdir? İki acil seçenek vardır. Birincisi, her tablo için bir yedek anahtar kullanarak bu sorunun var olduğunu fark etmek ve bunun gerçekleşmediğini doğrulamak için ek programlama getirmek. Bu uygulamada yapılabilir, ancak uygulama dışında ekler ve güncellemeler gerçekleşebilirse , yanlış ilişkilendirmeler yine de oluşabilir. Daha iyi bir yaklaşım, atanan bölümün atanan sınıflandırma ile aynı şirkette olduğundan emin olmak için bir çalışanın ekleme ve güncellemesini başlatan ve ekleme veya güncellemede başarısız olan bir tetikleyici oluşturmaktır.

İkinci seçenek, her tablo için yedek anahtar kullanmamaktır . Bunun yerine, yedek anahtarları yalnızca Companytemel olan ve ebeveynleri olmayan tablo için kullanın ve ardından ve alt tablolarıyla tanımlayıcı ilişkiler oluşturun . Ve tabloları artık bir PK var bunları ayırt etmek artı Sıra Numarası veya Ad. Daha sonra, gelen ilişkiler ve için de olmak ve böylece PK olur , ayrıca (bu örnekte bir sıra numarası kullanıyorum), artı . Sonuç sadece orada olduğu içinde masaya. Şimdi ise imkansız atama a kadarDepartmentClassificationDepartmentClassificationCompany IdDepartmentClassificationWorkeridentifyingWorkerCompany IdDepartment NumberClassification Numberone Company IdWorkerWorkerbir Departmentdiğerine Companyve Classificationdiğerine Company.

Bu neden imkansız? Bu imkansızdır çünkü şema Workerve Departmentve arasında referans bütünlüğü uygular Classification. Birini diğerine ve diğerine Workera eklemek için girişimde bulunulursa , karşılık gelen üst tabloda bulunmayan kombinasyon referans bütünlüğü ihlali tetikler ve ekleme çalışmaz.DepartmentCompanyClassification

İkinci seçeneğin uygulanmasının güncellenmiş bir şeması:

Tercih Edilen Seçenek

İki seçenekten, iki nedenden dolayı ikincisini - tanımlayıcı ilişkileri ve basamaklı tuşları kullanarak - kesinlikle tercih ederim. İlk olarak, bu seçenek ek bir programlama olmadan istenen kurala ulaşır. Bir tetikleyici geliştirmek önemsiz değildir. Kodlanmış, test edilmiş ve bakımı yapılmış olmalıdır. Performansı etkilememek için tetik mantığının optimum olmasını sağlamak da önemsiz değildir. Veritabanı Uzmanları için Uygulamalı Matematik kitabı , böyle bir çözümün karmaşıklığı hakkında birçok ayrıntı sunmaktadır. İkincisi, kurallar Bölümü ve Sınıflandırma ilişkin imalar değil bağlamında dışında var Companyşema artık daha doğru gerçek dünyayı yansıtır böylece, vb.

Bu harika bir soru, çünkü her tablonun neden bir yedek anahtar gerektirdiğini varsaymanın tam olarak neden kötü bir fikir olduğunu gösteriyor. Fabian Pascal bir sahip mükemmel blog yazısı sadece bir vekil anahtar aynı zamanda bazı alımlarını yaparak yol açabilecek veri bütünlüğü açısından kötü bir fikir olabilir değil gösteren sadece bu konu üzerine yavaşFiziksel düzeyde tam olarak, anahtarların düzgün bir şekilde basamaklandırılması gerektiğinde birleşme gerektiğinden gereksiz olacaktır. Bu sorunun ortaya koyduğu bir diğer ilginç konu, bir veritabanının içine eklenen tüm verilerin gerçek dünyaya göre doğru olduğundan emin olamamasıdır. Bunun yerine, yalnızca içine eklenen verilerin kendisine bildirilen kurallarla tutarlı olmasını sağlayabilir. Bu durumda biz basamaklı anahtarı yaklaşımını kullanarak mümkün olan en iyi yapabileceği sağlamak bir kuralına göre tutarlı veri tutabilir DBMS Workerbelirli bir bölgesinin Companyihtiyaçlarına bir atanacak Classificationve Departmento aynı Company. Ancak, gerçek dünyada Microsoftbir bölüm varsa Desktop Softwareancak veritabanının kullanıcısı bölümünSoftware Development DBMS hiçbir şey yapamaz ancak gerçek bir gerçek verildiğini varsayar.

Soruyu anladığım şekilde, 'İşçiler' tablosunun ID_Classification alanı yalnızca ilgili işçinin şirketi için tanımlanan sınıflandırmalara izin vermelidir. Bu nedenle, Workers.ID_Classification alanına eklenen / güncellenen bilgilerin doğrulanması (bir KURAL veya TRIGGERS aracılığıyla) bu gereksinimi karşılamak için yeterlidir.

Okumalarımdan hala bu Sınıflandırmanın ne olduğunu ve neden ID_Company'e sahip olması gerektiğini anlamıyorum . Eğer burada bahsettiğim gibi bir pozisyon gibi, ben tüm pozisyonları içeren statik bir tablo daha iyi olacağını düşünüyorum.

Bir şirkette kolayca bir sınıflandırma / pozisyon bulmak için bunu yapıyorsanız, lütfen sınıflandırma-işçi-departmanlarını bağlamak ve sınıflandırma şirket kimliğini almak için basit bir sorgu / görünüm ekleyin .

günümüzde, somutlaştırılmış görünümler ve birleştirilen dizinler gibi daha akıllı görünümler veya teknolojiler vardır, bu nedenle sorununuz sorgunun performansıysa bunları kullanın.