Saturday, 22 February 2020

Notasi IDEF1X - Data Modeling

05:21
Notasi IDEF1X - Data Modeling
Fahri Chaerul Fajri
Rachmantyo Arya Pradana
Sepdian Fauzi Putra
Nanda Naufal Ardatama
Kata Pengantar
Puji dan syukur penulis panjatkan atas kehadirat Allah S.W.T yang telah memberikan rahmat dan karunia-Nya. Shalawat dan salam semoga tercurahkan kepada baginda Nabi Muhammad S.A.W, beserta keluarga dan para sahabatnya. Serta tidak lupa penulis berterimakasih atas dorongan dan doa dari berbagai pihak sehingga dapat menyelesaikan penulisan ilmiah ini dengan sebaikbaiknya. Buku ini disusun guna memenuhi tugas mata kuliah Desain Pemodelan Grafik, di Universitas Gunadarma. Dalam proses penyusunan buku ini tidak lepas dari berbagai hambatan, namun atas bantuan dan dorongan dari berbagai pihak maka penulisan buku ini dapat diselesaikan. Tidak lupa Terimakasih kami ucapkan kepada Dosen mata kuliah Desain Pemodelan Grafik, Dr. rer. nat. I Made Wiryana, SKom, SSi, MAppSc, yang telah memberi kami tugas ini yang mana berguna baik bagi penulis maupun para pembaca sekalian.
Kami sadari bahwa dalam penulisan buku ini masih banyak kekurangan oleh karena itu diharapkan kirtik dan saran yang membangun dari semua pihak demi kesempurnaan buki ini.
Depok, 21 Januari 2020
BAB 1
0.1 Pendahuluan
0.1.1 Latar Belakang
Kebutuhan akan model data semantik pertama kali diakui oleh Angkatan Udara A.S. pada pertengahan tahun tujuh puluhan sebagai hasil dari Program Integrated Computer Aided Manufacturing (ICAM). Tujuan dari program ini adalah untuk meningkatkan produktivitas manufaktur melalui aplikasi sistematis teknologi komputer. Program ICAM mengidentifikasi kebutuhan akan analisis dan teknik komunikasi yang lebih baik untuk orang-orang yang terlibat dalam meningkatkan produktivitas manufaktur. Akibatnya, Program ICAM mengembangkan serangkaian teknik yang dikenal sebagai Metode IDEF (ICAM Definition) yang mencakup yang berikut:
1.                                  a) IDEF0 digunakan untuk menghasilkan "model fungsi" yang merupakan representasi terstruktur dari kegiatan atau proses dalam lingkungan atau sistem.
2.                                  b) IDEF1 digunakan untuk menghasilkan "model informasi" yang mewakili struktur dan semantik informasi dalam lingkungan atau sistem.
3.                                  c) IDEF2 digunakan untuk menghasilkan "model dinamika" yang mewakili karakteristik perilaku yang bervariasi dari lingkungan atau sistem. Pendekatan awal untuk pemodelan informasi IDEF (IDEF1) diterbitkan oleh program ICAM pada tahun 1981, berdasarkan penelitian saat ini dan kebutuhan industri. Akar teoritis untuk pendekatan ini berasal dari karya awal Dr. E. F. Codd tentang teori relasional dan Dr. P. P. S. Chen pada model entitas-hubungan.
Teknik IDEF1 awal didasarkan pada karya Dr. RR Brown dan Mr. TL Ramey dari Hughes Aircraft dan Mr. DS Coleman dari D. Appleton Company, dengan ulasan dan pengaruh kritis oleh Mr. CW Bachman, Dr. PPS Chen, Dr MA Melkanoff, dan Dr. GM Nijssen.
Pada tahun 1983, Angkatan Udara AS memulai proyek Sistem Dukungan Informasi Terpadu atau Integrated Information Support System (I2S2) di bawah program ICAM. Tujuan dari proyek ini adalah untuk menyediakan teknologi yang memungkinkan untuk secara logis dan fisik mengintegrasikan jaringan perangkat keras dan perangkat lunak komputer yang heterogen. Sebagai hasil dari proyek ini, dan pengalaman industri, kebutuhan akan teknik yang ditingkatkan untuk pemodelan informasi diakui.
Aplikasi dalam industri telah menyebabkan pengembangan pada tahun 1982 dari Teknik Desain Basis Data Logis (LDDT) oleh R. G. Brown dari Grup Desain Basis Data. Teknik ini didasarkan pada model relasional dari Dr. E. F. Codd, model hubungan entitas dari Dr. P. P. S. Chen, dan konsep generalisasi dari J. M. Smith dan D. C. P. Smith. Ini memberikan berbagai tingkatan model dan satu set grafik untuk mewakili pandangan konseptual informasi dalam suatu perusahaan. LDDT memiliki tingkat tumpang tindih yang tinggi dengan fitur IDEF1, memperkenalkan konstruksi semantik dan grafis yang disempurnakan, dan menangani persyaratan peningkatan pemodelan informasi yang diidentifikasi dalam program I2S2. Di bawah kepemimpinan teknis dari Dr. M. E. S. Loomis dari D. Appleton Company, sebagian besar LDDT dikombinasikan dengan metodologi IDEF1, dan diterbitkan oleh program ICAM pada tahun 1985. Teknik ini disebut IDEF1 Extended atau, secara sederhana, IDEF1X. Tujuan utama IDEF1X adalah untuk mendukung integrasi. Pendekatan I2S2 untuk integrasi berfokus pada penangkapan, pengelolaan, dan penggunaan definisi semantik tunggal dari sumber data yang disebut sebagai "Skema Konseptual." "Skema konseptual" memberikan definisi tunggal terintegrasi data dalam suatu perusahaan yang tidak memihak terhadap aplikasi tunggal data dan tidak tergantung pada bagaimana data disimpan atau diakses secara fisik. Tujuan utama skema konseptual ini adalah untuk memberikan definisi yang konsisten tentang makna dan keterkaitan data yang dapat digunakan untuk mengintegrasikan, berbagi, dan mengelola integritas data. Skema konseptual harus memiliki tiga karakteristik penting:
1.                                  a) Ini harus konsisten dengan infrastruktur bisnis dan benar di semua bidang aplikasi.
2.                                  b) Ini harus dapat diperpanjang, sedemikian sehingga, data baru dapat didefinisikan tanpa mengubah data yang didefinisikan sebelumnya.
3.                                  c) Ini harus dapat diubah baik untuk pandangan pengguna yang diperlukan maupun berbagai penyimpanan data dan struktur akses.
Bab 2
Ruang lingkup penggunaan notasi
IDEF1X adalah teknik pemodelan data semantik yang dijelaskan oleh dokumen ini. Teknik IDEF1X dikembangkan untuk memenuhi persyaratan berikut:
1.      Mendukung pengembangan skema konseptual. Sintaks IDEF1X mendukung konstruksi semantik yang diperlukan dalam pengembangan skema konseptual. Model IDEF1X yang dikembangkan sepenuhnya memiliki karakteristik yang diinginkan yaitu konsisten, dapat dikembangkan, dan dapat ditransformasikan.
2.      Jadilah bahasa yang koheren. IDEF1X memiliki struktur sederhana, konsisten bersih dengan konsep semantik yang berbeda. Sintaks dan semantik IDEF1X relatif mudah dipahami oleh pengguna, namun kuat dan kuat.
3.      Dapat diajar. Pemodelan data semantik adalah konsep baru bagi banyak pengguna IDEF1X. Karena itu, kemampuan mengajar bahasa menjadi pertimbangan penting. Bahasa ini dirancang untuk diajarkan dan digunakan oleh para profesional bisnis dan analis sistem serta administrator data dan perancang basis data. Dengan demikian, ini dapat berfungsi sebagai alat komunikasi yang efektif lintas tim interdisipliner.
4.      Diuji dan dibuktikan dengan baik. IDEF1X didasarkan pada pengalaman bertahun-tahun dengan teknik pendahulunya dan telah diuji secara menyeluruh baik dalam proyek pengembangan Angkatan Udara dan dalam industri swasta.
5.      Jadilah automatable. Diagram IDEF1X dapat dihasilkan oleh berbagai paket grafik. Selain itu, kamus tiga skema aktif telah dikembangkan oleh Angkatan Udara yang menggunakan skema konseptual yang dihasilkan untuk pengembangan aplikasi dan pemrosesan transaksi dalam lingkungan heterogen yang didistribusikan. Perangkat lunak komersial juga tersedia yang mendukung penyempurnaan, analisis, dan manajemen konfigurasi model IDEF1X.
Konstruksi dasar model IDEF1X adalah:
1.      Hal-hal tentang data mana yang disimpan, misalnya, orang, tempat, ide, acara, dll., Diwakili oleh kotak;
2.      Hubungan antara hal-hal itu, diwakili oleh garis-garis yang menghubungkan kotak; dan
3.      Karakteristik dari hal-hal tersebut diwakili oleh nama atribut di dalam kotak.
Elemen notasi
Sintaks dan Semantik IDEF1X
Bagian ini akan membahas level model IDEF1X, kontennya, aturan yang mengaturnya, dan berbagai bentuk di mana model dapat disajikan. Ini juga akan membahas semantik (atau makna) dari setiap komponen diagram IDEF1X, sintaksis grafis untuk mewakili komponen, dan aturan yang mengatur penggunaannya. Meskipun komponen-komponennya sangat saling terkait, masing-masing dibahas secara terpisah tanpa memperhatikan urutan konstruksi yang sebenarnya. Model IDEF1X terdiri dari satu atau lebih tampilan (sering disajikan dalam diagram tampilan yang mewakili semantik yang mendasari pandangan), dan definisi entitas dan domain (atribut) yang digunakan dalam tampilan. Ini dijelaskan di bagian ini. Lampiran A membahas prosedur untuk membangun model IDEF1X yang akan sesuai dengan sintaks dan semantik yang ditentukan.
Setiap model IDEF1X harus disertai dengan pernyataan tujuan (menjelaskan mengapa model itu diproduksi), pernyataan cakupan (menggambarkan area umum yang dicakup oleh model), dan deskripsi konvensi apa pun yang telah digunakan penulis selama konstruksi. Konvensi penulis tidak boleh melanggar aturan yang mengatur sintaksis model atau semantik.
Komponen dari IDEF1X adalah:
1.      Entities
1.      Identifier-Independent Entities
2.      Identifier-Dependent Entities
2.      Relationships
1.      Identifying Connection Relationships
2.      Non-Identifying Connection Relationships
3.      Categorization Relationships
4.      Non-Specific Relationships
3.      Attributes/Keys
1.      Attributes
2.      Primary Keys
3.      Alternate Keys
4.      Foreign Keys
4.      Notes
Bagian ini memberikan gambaran umum tentang IDEF1X. Setiap konstruk pemodelan dijelaskan dalam hal semantik umum, sintaksis, dan aturannya.
Entities
Entitas mewakili hal-hal yang menarik dalam tampilan IDEF1X. Mereka ditampilkan dalam diagram tampilan, dan didefinisikan dalam glosarium.
Entity Semantics
Entitas mewakili seperangkat benda nyata atau abstrak (orang, benda, tempat, peristiwa, gagasan, kombinasi benda, dll.) Yang memiliki atribut atau karakteristik umum. Seorang anggota individu set disebut sebagai "instance entitas." Objek atau benda dunia nyata dapat diwakili oleh lebih dari satu entitas dalam tampilan. Misalnya, John Doe dapat menjadi instance dari entitas EMPLOYEE dan PEMBELI. Selanjutnya, instance entitas dapat mewakili kombinasi objek dunia nyata. Sebagai contoh, John dan Mary dapat menjadi instance dari entitas MARRIED-COUPLE.
Suatu entitas adalah “pengidentifikasi-independen” atau hanya “independen” jika setiap instance entitas dapat diidentifikasi secara unik tanpa menentukan hubungannya dengan entitas lain. Suatu entitas adalah "tergantung pada pengidentifikasi" atau hanya "tergantung" jika identifikasi unik dari instance dari entitas tergantung pada hubungannya dengan entitas lain.
Entity Syntax
Suatu entitas direpresentasikan sebagai sebuah kotak seperti yang ditunjukkan pada Gambar 1. Jika entitas tersebut bergantung pada pengidentifikasi, maka sudut-sudut kotak tersebut bulat. Setiap entitas diberi label yang ditempatkan di atas kotak. Label harus mengandung nama entitas yang unik. Angka bilangan bulat positif juga dapat ditetapkan ke entitas sebagai bagian dari label. Angka akan dipisahkan oleh garis miring ("/"). 

Gambar 1. Entity Syntax
Nama entitas adalah frasa nomina yang menggambarkan sekumpulan hal yang diwakili entitas. Frasa kata benda adalah dalam bentuk tunggal, bukan jamak. Singkatan dan akronim diizinkan, namun, nama entitas harus bermakna dan konsisten di seluruh model. Definisi formal entitas dan daftar sinonim atau alias harus didefinisikan dalam glosarium. Meskipun suatu entitas dapat ditarik dalam sejumlah diagram, itu hanya muncul sekali dalam diagram yang diberikan.
Entity Rules
1.      Setiap entitas harus memiliki nama yang unik dan makna yang sama harus selalu berlaku untuk nama yang sama. Lebih jauh lagi, makna yang sama tidak dapat berlaku untuk nama yang berbeda kecuali nama tersebut alias.
2.      Dalam tampilan berbasis kunci atau atribut sepenuhnya, suatu entitas memiliki satu atau lebih atribut yang dimiliki oleh entitas atau dimigrasikan ke entitas melalui suatu hubungan.
3.      Dalam tampilan berbasis kunci atau atribut sepenuhnya, entitas memiliki satu atau lebih atribut yang nilainya mengidentifikasi secara unik setiap instance dari entitas.
4.      Entitas dapat memiliki sejumlah hubungan dengan entitas lain dalam tampilan.
5.      Jika seluruh kunci asing digunakan untuk semua atau sebagian dari kunci utama suatu entitas, maka entitas tersebut bergantung pada pengidentifikasi. Sebaliknya, jika hanya sebagian dari kunci asing atau tidak ada atribut kunci asing sama sekali yang digunakan untuk kunci primer entitas, maka entitas tersebut independen terhadap pengidentifikasi.
6.      Dalam suatu tampilan, suatu entitas diberi label dengan nama entitasnya atau salah satu aliasnya. Ini dapat dilabeli dengan nama yang berbeda (mis., Alias) dalam berbagai tampilan dalam model yang sama.
7.      Tidak ada tampilan yang bisa mengandung dua entitas yang dinamai secara berbeda di mana nama-nama tersebut sama. Dua nama sama artinya jika secara langsung atau tidak langsung merupakan alias untuk yang lain, atau ada nama ketiga yang kedua nama tersebut alias (baik secara langsung atau tidak langsung).
Domains
"Domain" mewakili serangkaian nilai yang ditentukan dan ditentukan dari satu atribut atau lebih yang menarik nilainya. Dalam IDEF1X, domain didefinisikan secara terpisah dari entitas dan tampilan untuk mengizinkan penggunaan kembali dan standarisasi di seluruh perusahaan.
Domain Semantics
Domain dianggap sebagai kelas yang memiliki instance, dan mungkin tak terbatas, instance. Misalnya, Kode Negara akan dianggap sebagai domain, di mana set nilai yang diijinkan untuk domain akan memenuhi definisi kode negara (misalnya pengidentifikasi unik suatu negara) dan mungkin terdiri dari singkatan dua huruf dari menyatakan. Contoh lain dari sebuah domain mungkin adalah Nama Belakang, yang memiliki sekumpulan nilai yang mendekati tak terhingga yang harus terdiri dari karakter alfabet [A-Z, a-z].
Domain dianggap sebagai kelas yang tidak dapat diubah yang nilainya tidak berubah seiring waktu. Sebaliknya, entitas adalah kelas yang bervariasi waktu, data instan mereka bervariasi dari waktu ke waktu seiring data dimodifikasi dan dipelihara. Sebagai kelas yang tidak dapat diubah, instance domain selalu ada pada prinsipnya. Ambil, misalnya, Tanggal domain, setiap instance dari tanggal ada atau akan ada, namun semua instance tanggal mungkin tidak digunakan sebagai instance dalam entitas yang berisi domain tanggal.
Setiap instance domain memiliki nilai unik dalam beberapa representasi - yaitu, unik dalam domain itu. Domain Kode Negara dapat menggunakan sejumlah representasi: Nama Lengkap [Alabama, Alaska, Arizona, ...], Singkatan [AL, AK, AZ, ...] atau Nomor Negara [1, 2, 3,. ..] Setiap representasi contoh harus unik dalam domain. Menggunakan huruf pertama dari negara sebagai representasi tidak valid [A, A, A].
Ada dua tipe dasar domain, domain dasar dan domain yang diketik.
Domain dasar dapat diberikan tipe data yang mungkin salah satu dari yang berikut: Karakter, Numerik atau Boolean. Tipe data lain seperti tanggal, waktu, biner, dll. Juga dapat digunakan, tetapi standar IDEF1X termasuk tiga dasar sebagai default.
Domain dasar juga dapat diberikan aturan domain. Aturan domain digunakan untuk memberikan nilai domain yang dapat diterima. Dua aturan domain yang paling umum adalah daftar nilai, dan aturan rentang.
Aturan domain daftar nilai menentukan set semua nilai instance yang dapat diterima untuk domain. Atribut domain dengan daftar nilai aturan domain hanya valid jika nilai instance mereka adalah bagian dari daftar nilai. Penggunaan umum aturan ini adalah untuk mendefinisikan daftar nilai kode seperti State-Code atau Titles [Mr, Mrs, ...].
Aturan domain rentang mendefinisikan himpunan semua nilai instance yang dapat diterima untuk domain di mana nilai instance dibatasi oleh batas bawah dan / atau atas. Contoh yang baik dari aturan domain rentang adalah Azimuth yang harus antara -360o hingga + 360o.
Akhirnya, untuk domain, aturan domain mungkin dibiarkan tidak ditentukan. Dalam kasus ini, domain hanya dibatasi oleh aturan yang terkait dengan tipe datanya atau tipe supernya jika memiliki salah satu dari keduanya. Nama Belakang adalah contoh domain tanpa aturan domain, dapat mengambil nilai karakter apa pun yang diizinkan.
Sebuah instance dari domain basis dianggap ada jika itu dari tipe data yang ditentukan, jika ada, dan memenuhi aturan domainnya.

Gambar 2. Example of a Domain Hierarchy
Domain Syntax
Tidak ada sintaksis konkret saat ini untuk domain di IDEF1X. Informasi domain harus disimpan dalam glosarium sebagai notasi informal yang menyatakan tipe data untuk domain dasar, hubungan sub-pengetikan untuk domain yang diketik, dan aturan dan representasi domain untuk semua domain.
Domain Rules
1.      Domain harus memiliki nama unik dan makna yang sama harus selalu berlaku untuk nama yang sama. Lebih jauh lagi, makna yang sama tidak dapat berlaku untuk nama yang berbeda kecuali nama tersebut alias.
2.      Domain adalah domain basis atau domain yang diketik.
3.      Domain dasar mungkin memiliki salah satu dari jenis berikut: karakter, numerik, atau boolean.
4.      Domain mungkin memiliki aturan domain.
5.      Aturan domain dinyatakan sebagai rentang atau daftar nilai.
6.      Aturan rentang membatasi instance yang valid dengan nilai lebih rendah dan / atau atas.
7.      Aturan daftar nilai membatasi instance yang valid untuk satu anggota dari serangkaian nilai.
8.      Domain yang diketik adalah sub-jenis domain basis atau domain yang diketik lainnya.
9.      Domain yang diketik merujuk domain yang merupakan subtipe dari.
10.  Tidak ada domain yang bisa secara langsung atau tidak langsung menjadi sub-tipe dari dirinya sendiri.
Views
"Tampilan" IDEF1X adalah kumpulan entitas dan domain yang ditugaskan (atribut) yang dikumpulkan untuk beberapa tujuan. Tampilan dapat mencakup seluruh area yang dimodelkan, atau bagian dari area itu. Model IDEF1X terdiri dari satu atau lebih tampilan (sering disajikan dalam diagram tampilan yang mewakili semantik yang mendasari pandangan), dan definisi entitas dan domain (atribut) yang digunakan dalam tampilan.
View Semantics
Dalam IDEF1X, entitas dan domain didefinisikan dalam glosarium umum dan dipetakan satu sama lain dalam pandangan. Dengan cara ini, entitas seperti EMPLOYEE dapat muncul dalam banyak tampilan, dalam banyak model, dan memiliki sekumpulan atribut yang agak berbeda di masing-masingnya. Dalam setiap tampilan, diperlukan bahwa entitas EMPLOYEE memiliki arti yang sama. Maksudnya adalah KARYAWAN menjadi kelas semua karyawan. Artinya, hal-hal individual diklasifikasikan sebagai milik kelas EMPLOYEE berdasarkan beberapa kesamaan. Perasaan tentang apa artinya menjadi karyawan yang didefinisikan dalam glosarium. Demikian pula, domain EMPLOYEE-NAME didefinisikan sekali, dan digunakan sebagai atribut dalam tampilan yang sesuai.
Tampilan diberi nama, dan, opsional, informasi deskriptif tambahan. Informasi opsional dapat mencakup nama penulis, tanggal yang dibuat dan direvisi terakhir, level (ER, berbasis kunci, sepenuhnya dikaitkan, dll.), Status penyelesaian atau peninjauan, dan sebagainya.
Deskripsi tekstual dari tampilan juga dapat diberikan. Deskripsi ini dapat berisi pernyataan naratif tentang hubungan dalam tampilan, deskripsi singkat tentang entitas dan atribut, dan diskusi tentang aturan atau batasan yang ditentukan.
View Syntax
Konstruk, yaitu, entitas, atribut (domain), hubungan, dan catatan yang digambarkan dalam diagram tampilan harus mematuhi semua sintaks dan aturan yang mengatur konstruk individual.
View Rules
1.      Setiap View harus memiliki nama unik.
2.      Konvensi penulis yang diadopsi untuk model harus konsisten di semua View yang termasuk dalam model.
3.      Setiap View yang mengandung sintaksis yang bertentangan dengan salah satu standar yang ditetapkan dalam dokumen ini harus diberi label "Hanya Untuk Eksposisi" (FEO).
4.      Model dapat berisi View dari berbagai tingkatan.
Attributes
Domain yang dikaitkan dengan entitas dalam tampilan disebut sebagai "atribut" entitas. Dalam tampilan IDEF1X, atribut dikaitkan dengan entitas tertentu.
Attribute Semantics
Dalam tampilan IDEF1X, "atribut" mewakili jenis karakteristik atau properti yang terkait dengan serangkaian hal nyata atau abstrak (orang, objek, tempat, acara, ide, kombinasi hal, dll.). "Contoh atribut" adalah karakteristik spesifik dari anggota individu set. Sebuah instance atribut didefinisikan oleh tipe karakteristik dan nilainya, yang disebut sebagai “nilai atribut.” Sebuah instance dari suatu entitas, kemudian, biasanya akan memiliki nilai spesifik tunggal untuk setiap atribut terkait. Misalnya, EMPLOYEENAME dan BIRTH-DATE dapat berupa atribut yang terkait dengan entitas EMPLOYEE. Sebuah instance dari entitas EMPLOYEE dapat memiliki nilai atribut "Jenny Lynne" dan "27 Februari 1953." Dalam situasi lain, tanggal lahir karyawan mungkin tidak diketahui saat instance entitas dibuat, dan atribut mungkin tidak memiliki nilai untuk beberapa periode waktu. Dalam kasus lain, atribut mungkin berlaku untuk satu contoh, tetapi tidak untuk yang lain. Misalnya, entitas WINDOW mungkin memiliki atribut COLOR. Dalam satu contoh, COLOR mungkin memiliki nilai "abu-abu". Di lain, mungkin tidak ada nilai (atribut mungkin nol) yang berarti bahwa jendela tidak memiliki warna (jendela jelas, oleh karena itu atribut tidak berlaku untuk kejadian ini).
Entitas harus memiliki atribut atau kombinasi atribut yang nilainya secara unik mengidentifikasi setiap instance entitas. Atribut-atribut ini membentuk "kunci utama" entitas. Sebagai contoh, atribut EMPLOYEE-NUMBER dapat berfungsi sebagai kunci utama untuk entitas EMPLOYEE, sedangkan atribut EMPLOYEE-NAME dan BIRTH-DATE akan menjadi atribut bukan kunci.
Dalam tampilan berbasis-kunci atau atribut-sepenuhnya, setiap atribut dimiliki hanya oleh satu entitas. Atribut MONTHLY-SALARY, misalnya, mungkin berlaku untuk beberapa instance entitas EMPLOYEE tetapi tidak semua. Oleh karena itu, entitas kategori terpisah namun terkait yang disebut SALARIED-EMPLOYEE dapat diidentifikasi untuk menetapkan kepemilikan untuk atribut MONTHLY-SALARY. Karena karyawan aktual yang digaji akan mewakili instansi entitas KARYAWAN dan KARYAWAN yang digaji, atribut yang sama untuk semua karyawan, seperti NAMA KARYAWAN dan TANGGAL KELAHIRAN, adalah atribut yang dimiliki entitas entitas KARYAWAN, bukan atribut yang digaji oleh KARYAWAN KERJA kesatuan. Atribut tersebut dikatakan “diwariskan” oleh entitas kategori, tetapi tidak termasuk dalam daftar atributnya: atribut tersebut hanya muncul dalam daftar atribut entitas generik.
Selain atribut yang "dimiliki" oleh suatu entitas, atribut dapat hadir dalam suatu entitas karena "migrasi" melalui hubungan koneksi tertentu, atau melalui hubungan kategorisasi. Misalnya, jika setiap karyawan ditugaskan ke suatu departemen, maka atribut DEPARTMENT-NUMBER dapat menjadi atribut EMPLOYEE yang telah dimigrasikan melalui hubungan dengan entitas EMPLOYEE dari entitas DEPARTMENT. Entitas DEPARTMENT akan menjadi pemilik atribut DEPARTMENT-NUMBER. Hanya atribut kunci primer yang dapat dimigrasikan melalui suatu hubungan. Atribut DEPARTMENT-NAME, misalnya, tidak akan menjadi atribut yang dimigrasi dari EMPLOYEE jika itu bukan bagian dari kunci utama untuk entitas DEPARTMENT.
Attribute Syntax
Setiap atribut diidentifikasi oleh nama unik dari domain yang mendasarinya. Nama tersebut dinyatakan sebagai frase nomina yang menggambarkan karakteristik yang diwakili oleh atribut. Frasa kata benda adalah dalam bentuk tunggal, bukan jamak. Singkatan dan akronim diizinkan, namun, nama atribut harus bermakna dan konsisten di seluruh model. Definisi formal dan daftar sinonim atau alias harus didefinisikan dalam glosarium.
Atribut ditampilkan dengan mendaftarkan nama mereka, di dalam kotak entitas terkait. Atribut yang mendefinisikan kunci utama ditempatkan di bagian atas daftar dan dipisahkan dari atribut lainnya oleh garis horizontal. Lihat Gambar 3.

Gambar 3. Attribute and Primary Key Syntax
Attribute Rules
1.      Atribut adalah pemetaan dari entitas dalam tampilan ke domain. Itu harus memiliki nama yang unik dan makna yang sama harus selalu berlaku untuk nama yang sama. Lebih jauh lagi, makna yang sama tidak dapat berlaku untuk nama yang berbeda kecuali nama tersebut alias.
2.      Entitas dapat memiliki sejumlah atribut. Dalam tampilan berbasis-kunci atau atribut-sepenuhnya, setiap atribut dimiliki oleh tepat satu entitas (disebut sebagai Aturan Pemilik Tunggal).
3.      Entitas dapat memiliki sejumlah atribut yang dimigrasi. Namun, atribut yang dimigrasi harus menjadi bagian dari kunci utama entitas induk terkait atau entitas generik.
4.      Setiap instance dari suatu entitas harus memiliki nilai untuk setiap atribut yang merupakan bagian dari kunci utamanya.
5.      Tidak ada instance dari entitas yang dapat memiliki lebih dari satu nilai untuk atribut yang terkait dengan entitas (disebut sebagai No-Repeat Rule).
6.      Atribut yang bukan bagian dari kunci primer dibiarkan nol (artinya tidak berlaku atau tidak dikenal) asalkan ditandai dengan jelas oleh simbol "(O)" (huruf besar O, untuk opsional) mengikuti atribut nama.
7.      Dalam suatu tampilan, atribut dilabeli dengan nama atributnya atau salah satu aliasnya. Jika itu adalah atribut yang dimiliki dalam satu entitas, dan atribut yang dimigrasikan di entitas lain, ia dapat memiliki nama yang sama di keduanya atau memiliki nama peran atau alias untuk nama peran sebagai atribut yang dimigrasikan. Atribut dapat diberi label dengan nama yang berbeda (mis., Alias) dalam tampilan yang berbeda dalam model yang sama.
8.      Tidak ada tampilan yang bisa mengandung dua atribut yang dinamai secara jelas di mana nama-nama tersebut sama. Dua nama sama artinya jika secara langsung atau tidak langsung merupakan alias untuk yang lain, atau ada nama ketiga yang kedua nama tersebut alias (baik secara langsung atau tidak langsung).
Connection Relationships
Dalam tampilan IDEF1X, hubungan koneksi digunakan untuk mewakili asosiasi antar entitas.
Specific Connection Relationship Semantics
"Hubungan koneksi spesifik" atau hanya "hubungan koneksi" (juga disebut sebagai "hubungan orang tua-anak") adalah asosiasi atau koneksi antara entitas di mana setiap instance dari satu entitas, disebut sebagai entitas induk, dikaitkan dengan nol, satu, atau lebih contoh entitas kedua, disebut sebagai entitas anak, dan setiap instance entitas anak dikaitkan dengan nol atau satu instance entitas induk. Misalnya, hubungan koneksi tertentu akan terjadi antara entitas PEMBELI dan PEMBELI PEMBELIAN, jika pembeli mengeluarkan nol, satu, atau lebih pesanan pembelian dan setiap pesanan pembelian harus dikeluarkan oleh satu pembeli. Diagram tampilan IDEF1X menggambarkan jenis atau rangkaian hubungan antara dua entitas. Sebuah instance spesifik dari hubungan mengaitkan instance spesifik dari entitas. Misalnya, "pembeli John Doe mengeluarkan Nomor Pesanan Pembelian 123" adalah sebuah instance dari suatu hubungan.
Hubungan koneksi dapat didefinisikan lebih lanjut dengan menentukan kardinalitas hubungan. Yaitu, spesifikasi berapa banyak instance entitas anak yang mungkin ada untuk setiap instance induk. Di dalam IDEF1X, kardinalitas hubungan berikut ini dapat diekspresikan dari perspektif entitas induk:
1.      Setiap instance entitas induk dapat memiliki nol atau lebih instance entitas anak terkait.
2.      Setiap instance entitas induk harus memiliki setidaknya satu instance entitas anak terkait.
3.      Setiap instance entitas induk dapat memiliki nol atau satu instance anak terkait.
4.      Setiap instance entitas induk dikaitkan dengan sejumlah instance instance entitas anak.
5.      Setiap instance entitas induk dikaitkan dengan rentang instance entitas anak yang ditentukan.
Kardinalitas juga dapat dideskripsikan dari perspektif entitas anak dan akan dijelaskan lebih lanjut di bagian selanjutnya.
Identifying Relationship Semantics
Jika turunan entitas anak diidentifikasi oleh hubungannya dengan entitas induk, maka hubungan tersebut disebut sebagai “hubungan identifikasi”, dan setiap instance entitas anak harus dikaitkan dengan tepat satu instance dari entitas induk. Misalnya, jika satu atau lebih tugas dikaitkan dengan setiap proyek dan tugas hanya diidentifikasi secara unik dalam suatu proyek, maka hubungan identifikasi akan ada antara entitas PROYEK dan TUGAS. Artinya, proyek terkait harus diketahui untuk mengidentifikasi secara unik satu tugas dari semua tugas lainnya. Anak dalam hubungan yang mengidentifikasi selalu bergantung pada orang tua, mis., Instance entitas anak hanya dapat ada jika terkait dengan instance entitas induk.
Non-Identifying Relationship Semantics
Jika setiap instance entitas anak dapat diidentifikasi secara unik tanpa mengetahui instance entitas induk yang terkait, maka hubungan tersebut disebut sebagai "hubungan yang tidak mengidentifikasi." Misalnya, meskipun hubungan keberadaan-ketergantungan mungkin ada antara entitas PEMBELI dan PEMBELI, pesanan pembelian dapat diidentifikasi secara unik oleh nomor pesanan pembelian tanpa mengidentifikasi pembeli yang terkait.
Specific Connection Relationship Syntax
Hubungan koneksi spesifik digambarkan sebagai garis yang ditarik antara entitas induk dan entitas anak dengan titik di ujung anak dari garis tersebut. Kardinalitas anak standar adalah nol, satu atau banyak. "P" (untuk positif) ditempatkan di samping titik untuk menunjukkan kardinalitas satu atau lebih. "Z" ditempatkan di samping titik untuk menunjukkan kardinalitas nol atau satu. Jika kardinalitas adalah angka pastinya, bilangan bulat positif ditempatkan di sebelah titik. Jika kardinalitas adalah suatu rentang, kisaran ditempatkan di samping titik. Lihat Gambar 4. Kardinalitas lain (misalnya, lebih dari 3, tepatnya 7 atau 9), dicatat sebagai catatan yang ditempatkan di samping titik.

Gambar 4. Relationship Cardinality Syntax
Identifying Relationship Syntax
Garis yang solid menggambarkan hubungan identifikasi antara entitas induk dan anak. Lihat Gambar 5. Jika hubungan pengidentifikasi ada, entitas anak selalu merupakan entitas yang bergantung pada pengidentifikasi, diwakili oleh kotak sudut bulat, dan atribut kunci primer dari entitas induk juga dimigrasikan atribut kunci primer dari entitas anak.


Gambar 5. Identifying Relationship Syntax
Entitas induk dalam hubungan pengidentifikasian akan independen-pengidentifikasi kecuali entitas induk juga merupakan entitas anak dalam beberapa hubungan pengidentifikasi lainnya, dalam hal ini entitas induk dan anak akan bergantung pada pengidentifikasi. Suatu entitas dapat memiliki satu atau lebih hubungan dengan entitas lain. Namun, jika entitas adalah entitas anak dalam hubungan identifikasi apa pun, entitas tersebut selalu ditampilkan sebagai entitas yang bergantung pada pengidentifikasi dengan sudut bulat, terlepas dari perannya dalam hubungan lainnya.
Non-Identifying Relationship Syntax
Garis putus-putus menggambarkan hubungan yang tidak mengidentifikasi antara entitas induk dan anak. Entitas induk dan anak akan menjadi entitas pengidentifikasi-independen dalam hubungan yang tidak mengidentifikasi kecuali salah satu atau keduanya adalah entitas anak dalam beberapa hubungan lain yang merupakan hubungan yang mengidentifikasi.
Mandatory Non-Identifying Relationship Syntax
Dalam hubungan wajib mengidentifikasi, setiap instance dari entitas anak terkait dengan tepat satu instance dari entitas induk. Lihat Gambar 6.

Gambar 6. Mandatory Non-Identifying Relationship Syntax
Optional Non-Identifying Relationship Syntax
Garis putus-putus dengan berlian kecil di ujung induk menggambarkan hubungan opsional yang tidak mengidentifikasi antara entitas induk dan anak. Lihat Gambar 7. Dalam hubungan opsional yang tidak mengidentifikasi, setiap instance dari entitas anak terkait dengan nol atau satu instance dari entitas induk. Hubungan non-identifikasi opsional mewakili ketergantungan keberadaan kondisional. Sebuah instance dari anak di mana setiap atribut kunci asing untuk suatu hubungan memiliki suatu nilai harus memiliki instance induk terkait di mana atribut kunci primer dari nilai induk sama nilainya dengan atribut kunci asing anak tersebut.

Gambar 7. Optional Non-Identifying Relationship Syntax
Specific Connection Relationship Label
Suatu hubungan diberi nama, diekspresikan sebagai kata kerja atau frasa kata kerja yang ditempatkan di sebelah garis hubungan. Nama setiap hubungan antara dua entitas yang sama harus unik, tetapi nama hubungan tidak harus unik dalam model. Nama hubungan untuk hubungan koneksi tertentu biasanya dinyatakan dalam arah orangtua-ke-anak, sehingga kalimat dapat dibentuk dengan menggabungkan nama entitas induk, nama hubungan, ekspresi kardinalitas, dan nama entitas anak. Misalnya, pernyataan "Suatu proyek mendanai satu atau lebih tugas" dapat diturunkan dari hubungan yang menunjukkan PROYEK sebagai entitas induk, TUGAS sebagai entitas anak dengan simbol kardinalitas "P", dan "dana" sebagai nama hubungan. Ketika suatu hubungan dinamai dari perspektif orang tua dan anak, perspektif orang tua dinyatakan pertama, diikuti oleh simbol "/" dan kemudian dari perspektif anak. Perhatikan bahwa hubungan harus tetap benar ketika dinyatakan dari arah sebaliknya jika hubungan anak-ke-orang tua tidak disebutkan secara eksplisit. Dari contoh sebelumnya, disimpulkan bahwa "tugas didanai oleh satu proyek." Perspektif anak di sini direpresentasikan sebagai “didanai oleh”. Label hubungan lengkap untuk contoh ini, termasuk perspektif orang tua dan anak, akan “didanai / didanai oleh”. Perspektif orang tua harus dinyatakan untuk semua hubungan koneksi spesifik.
Metode kedua dapat digunakan untuk memberi nama hubungan dari perspektif anak. Objek langsung frasa dapat digunakan sebagai pengganti seluruh frasa kata kerja. Ungkapan kata kerja selesai ketika membaca hubungan dengan memasukkan istilah tersirat "memiliki". Pola untuk membaca hubungan yang dijelaskan dalam gaya ini adalah "A <child entity name> memiliki <cardinality> <object object> <parent entity name>". Menggunakan contoh sebelumnya dari hubungan antara proyek dan tugas, objek langsung dari frasa adalah "dana" Label hubungan penuh kemudian menjadi "dana / dana". Hubungan terbalik dibaca "tugas memiliki tepat satu proyek pendanaan".
Specific Connection Relationship Rules
1.      Hubungan koneksi spesifik selalu antara tepat dua entitas, entitas induk dan entitas anak.
2.      Dalam hubungan identifikasi, dan dalam hubungan non-identifikasi wajib, setiap instance dari entitas anak harus selalu dikaitkan dengan tepat satu instance dari entitas induknya.
3.      Dalam hubungan opsional yang tidak mengidentifikasi, setiap instance dari entitas anak harus selalu dikaitkan dengan nol atau satu instance dari entitas induknya.
4.      Sebuah instance dari entitas induk dapat dikaitkan dengan nol, satu, atau lebih instance dari entitas anak tergantung pada kardinalitas yang ditentukan.
5.      Entitas anak dalam hubungan identifikasi selalu merupakan entitas yang bergantung pada pengidentifikasi.
6.      Entitas anak dalam hubungan yang tidak mengidentifikasi akan menjadi entitas pengidentifikasi-independen kecuali jika entitas tersebut juga merupakan entitas anak dalam suatu hubungan identifikasi.
7.      Entitas dapat dikaitkan dengan sejumlah entitas lain baik sebagai anak atau orang tua.
8.      Hanya hubungan yang tidak mengidentifikasi yang dapat bersifat rekursif, mis., Dapat menghubungkan sebuah instance dari entitas dengan instance lain dari entitas yang sama.
Categorization Relationships
Hubungan kategorisasi digunakan untuk mewakili struktur di mana suatu entitas adalah "tipe" (kategori) dari entitas lain.
Kategorisasi Hubungan Entitas Semantik digunakan untuk mewakili gagasan tentang "hal-hal yang kita perlukan informasi." Karena beberapa benda dunia nyata adalah kategori benda dunia nyata lainnya, beberapa entitas harus, dalam beberapa hal, menjadi kategori entitas lain. Sebagai contoh, anggaplah karyawan adalah sesuatu tentang informasi mana yang dibutuhkan. Meskipun ada beberapa informasi yang diperlukan tentang semua karyawan, informasi tambahan mungkin diperlukan tentang karyawan yang digaji berbeda, dari informasi tambahan yang dibutuhkan tentang karyawan per jam. Oleh karena itu, entitas SALARIED-EMPLOYEE dan HOURLY-EMPLOYEE adalah kategori entitas EMPLOYEE. Dalam tampilan IDEF1X, mereka terkait satu sama lain melalui hubungan kategorisasi.
Dalam kasus lain, entitas kategori mungkin diperlukan untuk mengekspresikan hubungan yang hanya valid untuk kategori tertentu, atau untuk mendokumentasikan perbedaan hubungan di antara berbagai kategori entitas. Sebagai contoh, suatu FULL-TIME-EMPLOYEE dapat memenuhi syarat untuk MANFAAT, sementara PART-TIME-EMPLOYEE mungkin tidak memenuhi syarat.
"Hubungan kategorisasi" adalah hubungan antara satu entitas, disebut sebagai "entitas generik", dan entitas lain, disebut sebagai "entitas kategori". "Klaster kategori" adalah sekumpulan hubungan kategorisasi atau lebih. Sebuah instance dari entitas generik dapat dikaitkan dengan sebuah instance hanya dari satu entitas kategori dalam cluster, dan setiap instance dari entitas kategori dikaitkan dengan tepat satu instance dari entitas generik. Setiap instance dari entitas kategori mewakili hal dunia nyata yang sama dengan instance terkaitnya dalam entitas generik. Dari contoh sebelumnya, EMPLOYEE adalah entitas generik dan SALARIED-EMPLOYEE dan HOURLY-EMPLOYEE adalah entitas kategori. Ada dua hubungan kategorisasi dalam cluster ini, satu antara EMPLOYEE dan SALARIED-EMPLOYEE dan satu lagi antara EMPLOYEE dan HOURLY-EMPLOYEE.
Karena instance entitas generik tidak dapat dikaitkan dengan instance lebih dari satu entitas kategori dalam cluster, entitas kategori tersebut saling eksklusif. Dalam contoh ini, ini menyiratkan bahwa seorang karyawan tidak dapat digaji dan setiap jam. Namun, suatu entitas dapat menjadi entitas generik di lebih dari satu kategori cluster, dan entitas kategori dalam satu cluster tidak saling terpisah dengan yang lainnya. Sebagai contoh, EMPLOYEE dapat menjadi entitas generik dalam kelompok kategori kedua dengan FEMALEEMPLOYEE dan MALE-EMPLOYEE sebagai entitas kategori. Sebuah instance dari EMPLOYEE dapat dikaitkan dengan sebuah instance dari baik SALARIED-EMPLOYEE atau HOURLY-EMPLOYEE dan dengan sebuah instance baik FEMALE-EMPLOYEE atau MALE-EMPLOYEE.
Dalam "cluster kategori lengkap", setiap instance dari entitas generik dikaitkan dengan instance dari entitas kategori, yaitu, semua kategori yang mungkin ada. Misalnya, setiap karyawan adalah laki-laki atau perempuan, sehingga klaster kedua selesai. Dalam "cluster kategori tidak lengkap", sebuah instance dari entitas generik dapat eksis tanpa dikaitkan dengan instance dari entitas kategori mana pun, yaitu, beberapa kategori dihilangkan. Misalnya, jika beberapa karyawan dibayar komisi daripada upah per jam atau gaji, kelompok kategori pertama tidak akan lengkap.
Atribut di entitas generik, atau di salah satu leluhurnya, dapat ditetapkan sebagai pembeda untuk kelompok kategori tertentu dari entitas itu. Nilai diskriminator menentukan kategori turunan generik. Pada contoh sebelumnya, diskriminator untuk klaster termasuk kategori yang digaji dan per jam dapat dinamai EMPLOYEE-TYPE. Jika sebuah cluster memiliki diskriminator, itu harus berbeda dari semua diskriminator lainnya.
Kategorisasi Hubungan Sintaksis Klaster kategori ditampilkan sebagai garis yang memanjang dari entitas generik ke lingkaran yang digarisbawahi. Garis terpisah terbentang dari lingkaran yang digarisbawahi ke masing-masing entitas kategori dalam gugus. Setiap pasangan garis, dari entitas generik ke lingkaran dan dari lingkaran ke entitas kategori, mewakili salah satu hubungan kategorisasi dalam gugus. Kardinalitas tidak ditentukan untuk entitas kategori karena selalu nol atau satu. Entitas kategori juga selalu bergantung pada pengidentifikasi. Lihat Gambar 8. Entitas generik independen kecuali pengidentifikasinya telah bermigrasi melalui beberapa hubungan lain.

Gambar 8. Categorization Relationship Syntax
Jika lingkaran memiliki garis bawah ganda, ini menunjukkan bahwa himpunan entitas kategori selesai. Satu baris di bawah lingkaran menunjukkan seperangkat kategori yang tidak lengkap. Nama atribut yang digunakan sebagai pembeda (jika ada) ditulis dengan lingkaran. Meskipun hubungan kategorisasi itu sendiri tidak disebutkan secara eksplisit, setiap entitas generik ke hubungan entitas kategori dapat dibaca sebagai "bisa." Sebagai contoh, seorang KARYAWAN dapat menjadi KARYAWAN YANG DI-SALARIED. Jika serangkaian kategori lengkap direferensikan, hubungan tersebut dapat dibaca sebagai "harus." Misalnya, seorang KARYAWAN harus seorang MALE-KARYAWAN atau seorang FEMALE-KARYAWAN. Hubungan dibaca sebagai "adalah /" dari arah sebaliknya. Misalnya, seorang JAM KERJA-KARYAWAN adalah KARYAWAN. Entitas generik dan setiap entitas kategori harus memiliki atribut primary key yang sama. Namun, nama peran dapat digunakan dalam entitas kategori.
Categorization Relationship Rules
1.      Entitas kategori hanya dapat memiliki satu entitas generik. Artinya, itu hanya bisa menjadi anggota dari set kategori untuk satu cluster kategori.
2.      Entitas kategori dalam satu hubungan kategorisasi dapat berupa entitas generik dalam hubungan kategorisasi lain.
3.      Suatu entitas dapat memiliki sejumlah cluster kategori di mana ia adalah entitas generik. (Misalnya, FEMALE-EMPLOYEE dan MALE-EMPLOYEE dapat berupa kelompok kategori kedua untuk entitas generik EMPLOYEE.)
4.      Atribut kunci utama entitas kategori harus sama dengan atribut kunci primer entitas generik. Namun, nama peran dapat ditetapkan dalam entitas kategori.
5.      Semua instance dari entitas kategori memiliki nilai diskriminator yang sama dan semua instance dari kategori yang berbeda harus memiliki nilai diskriminator yang berbeda.
6.      Tidak ada entitas yang dapat menjadi leluhur generiknya sendiri, yaitu, tidak ada entitas yang dapat memiliki dirinya sebagai orang tua dalam hubungan kategorisasi, juga tidak dapat berpartisipasi dalam serangkaian hubungan kategorisasi yang menentukan siklus.
7.      Tidak ada dua kelompok kategori entitas generik yang dapat memiliki pembeda yang sama.
8.      Diskriminator (jika ada) dari cluster kategori lengkap tidak boleh merupakan atribut opsional. Entitas kategori tidak bisa menjadi entitas anak dalam hubungan koneksi yang mengidentifikasi kecuali kunci utama yang dikontribusikan oleh hubungan identifikasi sepenuhnya terkandung dalam kunci utama kategori, sementara pada saat yang sama kunci utama kategori memenuhi aturan d di atas.
Non-Specific Relationships
Hubungan non-spesifik digunakan dalam pandangan Entity-Relationship tingkat tinggi untuk mewakili banyak-ke-banyak asosiasi antar entitas.
Semantik Hubungan Non-Spesifik Baik hubungan orang tua-anak dan hubungan kategorisasi dianggap hubungan spesifik karena mereka mendefinisikan dengan tepat bagaimana instance dari satu entitas terkait dengan instance dari entitas lain. Dalam pandangan berbasis kunci atau atribut sepenuhnya, semua asosiasi antara entitas harus dinyatakan sebagai hubungan spesifik. Namun, dalam pengembangan awal model, seringkali membantu untuk mengidentifikasi "hubungan non-spesifik" antara entitas. Hubungan non-spesifik ini disempurnakan dalam fase pengembangan selanjutnya dari model.
Hubungan non-spesifik, juga disebut sebagai "hubungan banyak-ke-banyak," adalah hubungan antara dua entitas di mana setiap instance dari entitas pertama dikaitkan dengan nol, satu, atau banyak contoh dari entitas kedua dan masing-masing instance dari entitas kedua dikaitkan dengan nol, satu, atau banyak instance dari entitas pertama. Misalnya, jika seorang karyawan dapat ditugaskan ke banyak proyek dan sebuah proyek dapat memiliki banyak karyawan yang ditugaskan, maka hubungan antara entitas EMPLOYEE dan PROYEK dapat dinyatakan sebagai hubungan non-spesifik. Hubungan non-spesifik ini dapat diganti dengan hubungan spesifik nanti dalam pengembangan model dengan memperkenalkan entitas ketiga, seperti PROJECTASSIGNMENT, yang merupakan entitas anak yang umum dalam hubungan koneksi spesifik dengan entitas EMPLOYEE dan PROJECT. Hubungan baru akan menentukan bahwa seorang karyawan memiliki nol, satu, atau lebih tugas proyek. Setiap tugas proyek tepat untuk satu karyawan dan tepat satu proyek. Entitas yang diperkenalkan untuk menyelesaikan hubungan non-spesifik kadang-kadang disebut entitas "persimpangan" atau "asosiatif".
Non-Specific Relationship Syntax
Hubungan non-spesifik digambarkan sebagai garis yang ditarik antara dua entitas yang terkait dengan titik di setiap ujung garis. Lihat Gambar 9. Kardinalitas dapat diekspresikan di kedua ujung hubungan seperti yang ditunjukkan pada Gambar 4. "P" (untuk positif) yang ditempatkan di samping titik menunjukkan bahwa untuk setiap instance entitas di ujung lain dari hubungan ada satu atau lebih contoh entitas di akhir dengan "P." "Z" yang ditempatkan di samping titik menunjukkan bahwa untuk setiap instance entitas di ujung lain dari hubungan ada nol atau satu contoh entitas di akhir dengan "Z." Dengan cara yang sama, bilangan bulat positif atau rentang bilangan bulat positif minimum dan maksimum dapat ditempatkan di samping titik untuk menentukan kardinalitas yang tepat. Kardinalitas default adalah nol, satu, atau lebih.
Hubungan non-spesifik dapat disebutkan di kedua arah. Label hubungan dinyatakan sebagai pasangan frasa kata kerja yang ditempatkan di sebelah garis hubungan dan dipisahkan oleh garis miring, (“/.”) Urutan frasa kata kerja tergantung pada posisi relatif entitas. Yang pertama menyatakan hubungan dari entitas kiri ke entitas kanan, jika entitas diatur secara horizontal, atau entitas atas ke entitas bawah, jika mereka diatur secara vertikal. Yang kedua menyatakan hubungan dari arah lain, yaitu, entitas kanan ke entitas kiri atau entitas bawah ke entitas atas, sekali lagi tergantung pada orientasi. Orientasi atas-ke-bawah diutamakan daripada kiri-ke-kanan, jadi jika entitas disusun atas kanan dan kiri bawah, frasa kata kerja pertama menjelaskan hubungan dari perspektif entitas atas. Hubungan dilabeli sedemikian rupa sehingga kalimat dapat dibentuk dengan menggabungkan nama entitas dengan frasa. Misalnya, pernyataan “Suatu proyek memiliki nol, satu, atau lebih banyak karyawan” dan “Seorang karyawan ditugaskan nol, satu, atau lebih banyak proyek” dapat diturunkan dari hubungan non-spesifik berlabel “telah / ditugaskan” antara entitas PROYEK dan KARYAWAN. (Urutan mengasumsikan PROYEK muncul di atas atau di sebelah kiri entitas EMPLOYEE.)

Gambar 9. Non-Specific Relationship Syntax
Non-Specific Relationship Rules
1.      Hubungan non-spesifik selalu antara dua entitas.
2.      Sebuah instance dari salah satu entitas dapat dikaitkan dengan nol, satu, atau lebih instance dari entitas lain tergantung pada kardinalitas yang ditentukan.
3.      Dalam tampilan berbasis kunci atau atribut sepenuhnya, semua hubungan non-spesifik harus diganti oleh hubungan spesifik.
4.      Hubungan non-spesifik dapat bersifat rekursif, mis., Dapat menghubungkan sebuah instance dari entitas ke instance lain dari entitas yang sama.
Primary and Alternate Keys
Kunci primer dan alternatif mewakili batasan keunikan atas nilai atribut entitas.
Primary and Alternate Key Semantics
“Kandidat key” dari suatu entitas adalah satu atau lebih atribut yang nilainya secara unik mengidentifikasi setiap instance entitas. Sebagai contoh, atribut PURCHASE-ORDER-IDENTIFIER dapat secara unik mengidentifikasi instance entitas PURCHASE-ORDER. Kombinasi atribut ACCOUNT-IDENTIFIER dan CHECK-IDENTIFIER dapat secara unik mengidentifikasi contoh entitas CHECK.
Dalam tampilan berbasis kunci dan atribut sepenuhnya, setiap entitas harus memiliki setidaknya satu kunci kandidat. Dalam beberapa kasus, suatu entitas dapat memiliki lebih dari satu atribut atau kelompok atribut yang secara unik mengidentifikasi contoh-contoh entitas. Sebagai contoh, atribut EMPLOYEE-IDENTIFIER dan EMPLOYEE-SOSIAL-SECURITYNUMBER dapat secara unik mengidentifikasi instance entitas EMPLOYEE. Jika ada lebih dari satu kunci kandidat, maka satu kunci kandidat ditetapkan sebagai "kunci utama" dan kunci kandidat lainnya ditetapkan sebagai "kunci alternatif." Jika hanya satu kunci kandidat yang ada, maka tentu saja itu adalah kunci utama.
Primary and Alternate Key Syntax
Atribut yang mendefinisikan kunci utama ditempatkan di bagian atas daftar atribut dalam kotak entitas dan dipisahkan dari atribut lainnya oleh garis horizontal. Lihat Gambar 3.
Setiap kunci alternatif ditetapkan angka integer unik dan ditunjukkan dengan menempatkan catatan "AK" ditambah nomor kunci alternatif dalam tanda kurung, misalnya, "(AK1)," di sebelah kanan setiap atribut dalam kunci. Lihat Gambar 10 Atribut individual dapat diidentifikasi sebagai bagian dari lebih dari satu kunci alternatif. Atribut kunci primer juga dapat berfungsi sebagai bagian dari kunci alternatif.

Gambar 10. Alternate Key Syntax
Primary and Alternate Key Rules
1.      Dalam tampilan IDEF1X berbasis kunci atau sepenuhnya dikaitkan, setiap entitas harus memiliki kunci utama.
2.      Entitas mungkin memiliki sejumlah kunci alternatif.
3.      Kunci primer atau alternatif dapat terdiri dari atribut tunggal atau kombinasi atribut.
4.      Atribut individual dapat menjadi bagian dari lebih dari satu kunci, baik primer atau alternatif.
5.      Atribut yang membentuk kunci primer dan alternatif dari suatu entitas dapat dimiliki oleh entitas tersebut atau dimigrasikan melalui suatu hubungan.
6.      Kunci primer dan alternatif harus hanya berisi atribut yang berkontribusi pada identifikasi unik (yaitu, jika atribut apa pun tidak dimasukkan sebagai bagian dari kunci, maka setiap instance entitas tidak dapat diidentifikasi secara unik; disebut sebagai Aturan Terkecil-Kunci). ).
7.      Jika kunci utama terdiri dari lebih dari satu atribut, nilai setiap atribut non-kunci harus secara fungsional bergantung pada seluruh kunci primer, yaitu, jika kunci primer diketahui, nilai dari setiap atribut non-kunci adalah diketahui, dan tidak ada nilai atribut non-kunci yang dapat ditentukan hanya dengan bagian dari kunci primer (disebut Aturan Ketergantungan Penuh-Fungsional).
8.      Setiap atribut yang bukan bagian dari kunci primer atau alternatif harus secara fungsional bergantung hanya pada kunci primer dan masing-masing kunci alternatif, yaitu, tidak ada nilai atribut yang dapat ditentukan oleh nilai atribut lain tersebut (disebut sebagai Tidak Aturan -Transitif-Ketergantungan).
Foreign Keys
Foreign keys adalah atribut dalam entitas yang menunjuk instance dari entitas terkait.
Foreign Key Semantics
Jika hubungan atau kategorisasi hubungan tertentu ada antara dua entitas, maka atribut yang membentuk kunci utama dari entitas induk atau generik dimigrasikan sebagai atribut entitas anak atau entitas kategori. Atribut yang dimigrasikan ini disebut sebagai "kunci asing." Misalnya, jika ada hubungan koneksi antara entitas PROJECT sebagai orang tua dan entitas TASK sebagai anak, maka atribut kunci utama PROJECT akan menjadi atribut yang dimigrasi dari entitas TASK. Sebagai contoh, jika atribut PROJECT-ID adalah kunci utama dari PROJECT, maka PROJECT-ID juga akan menjadi atribut yang dimigrasi atau kunci asing TUGAS.
Atribut yang dimigrasi dapat digunakan sebagai bagian atau total kunci primer, kunci alternatif, atau atribut non-kunci dalam suatu entitas. Jika semua atribut kunci utama entitas induk dimigrasikan sebagai bagian dari kunci utama entitas anak, maka hubungan yang dilalui atribut tersebut adalah "hubungan identifikasi." Jika salah satu atribut yang dimigrasi bukan bagian dari kunci utama entitas anak, maka hubungannya adalah “hubungan yang tidak mengidentifikasi”. Sebagai contoh, jika tugas-tugas hanya diberi nomor unik dalam suatu proyek, maka atribut bermigrasi PROJECT-ID akan digabungkan dengan atribut yang dimiliki TASK-ID untuk menentukan kunci utama TASK. Entitas PROYEK akan memiliki hubungan identifikasi dengan entitas TUGAS. Jika di sisi lain, atribut TASK-ID selalu unik, bahkan di antara proyek, maka atribut bermigrasi PROJECT-ID akan menjadi atribut non-kunci dari entitas TASK. Dalam hal ini, entitas PROJECT akan memiliki hubungan yang tidak mengidentifikasi dengan entitas TUGAS. Ketika hanya sebagian dari kunci primer yang dimigrasi menjadi bagian dari kunci utama entitas anak, dengan sisanya menjadi atribut non-kunci anak, kunci asing yang disumbangkan disebut "kunci split". Jika kunci "terpecah", hubungannya tidak dapat diidentifikasi.
Dalam hubungan kategorisasi, entitas generik dan entitas kategori mewakili hal dunia nyata yang sama. Oleh karena itu, kunci utama untuk semua entitas kategori dimigrasikan melalui hubungan kategorisasi dari kunci primer entitas generik. Misalnya, jika SALARIED-EMPLOYEE dan HOURLY-EMPLOYEE adalah entitas kategori dan EMPLOYEE adalah entitas generik, maka jika atribut EMPLOYEE-IDENTIFIER adalah kunci utama untuk entitas EMPLOYEE, itu juga akan menjadi kunci utama untuk entitas SALARIED-EMPLOYEE dan HOURLY-EMPLOYEE.
Dalam beberapa kasus, entitas anak mungkin memiliki beberapa hubungan dengan entitas induk yang sama. Kunci utama entitas induk akan muncul sebagai atribut yang dimigrasi dalam entitas anak untuk setiap hubungan. Untuk instance entitas anak tertentu, nilai atribut yang dimigrasikan mungkin berbeda untuk setiap hubungan, mis., Dua contoh entitas entitas yang berbeda dapat dirujuk. RUU struktur material, misalnya, dapat diwakili oleh dua entitas BAGIAN dan BAGIAN-PERAKITAN-STRUKTUR. Entitas PART memiliki hubungan ganda sebagai entitas induk dengan entitas PART-ASSEMBLY-STRUKTUR. Bagian yang sama kadang-kadang bertindak sebagai komponen dari mana rakitan dibuat, yaitu, bagian dapat menjadi komponen dalam satu atau lebih rakitan, dan kadang-kadang bertindak sebagai rakitan di mana komponen dirakit, yaitu, bagian mungkin merupakan rakitan untuk satu atau lebih banyak komponen. Jika kunci utama untuk entitas PART adalah PART-IDENT, maka PART-IDENT akan muncul dua kali di entitas PART-ASSEMBLY-STRUKTUR sebagai atribut yang dimigrasikan. Namun, karena atribut hanya dapat muncul sekali dalam entitas apa pun, dua kemunculan PART-IDENT di PART-ASSEMBLY-STRUKTUR digabung kecuali jika nama peran diberikan untuk satu atau keduanya.
Role Name Semantics
Ketika suatu atribut bermigrasi ke suatu entitas melalui lebih dari satu hubungan, "nama peran" mungkin perlu ditugaskan untuk setiap kejadian untuk membedakan di antara mereka. Jika instance entitas dapat memiliki satu nilai untuk satu kejadian, dan nilai lainnya untuk yang lain, maka setiap kejadian harus diberi nama peran yang berbeda. Di sisi lain, jika setiap instance entitas harus memiliki nilai yang sama untuk dua kejadian atau lebih, mereka masing-masing harus memiliki nama yang sama. Dari contoh sebelumnya, nama peran KOMPONEN-PARTIDEN dan ASSEMBLY-PART-IDENT harus ditugaskan untuk membedakan antara dua kejadian atribut PART-IDENT yang dimigrasi. Meskipun tidak diperlukan, nama peran juga dapat digunakan dengan kemunculan tunggal atribut yang dimigrasikan untuk lebih tepatnya menyampaikan maknanya dalam konteks entitas anak.
Foreign Key Syntax
Foreign key ditunjukkan dengan menempatkan nama atribut yang dimigrasikan di dalam kotak entitas dan dengan mengikuti masing-masing dengan huruf "FK" dalam tanda kurung, mis., "(FK)." Lihat Gambar 11. Jika semua atribut yang dimigrasikan milik kunci primer entitas anak, masing-masing ditempatkan di atas garis horizontal dan entitas digambar dengan sudut bulat untuk menunjukkan bahwa pengidentifikasi (kunci primer) entitas tergantung pada atribut bermigrasi melalui suatu hubungan. Jika atribut yang dimigrasi bukan milik kunci utama entitas anak, atribut ditempatkan di bawah garis, dan bentuk entitas dapat dibulatkan atau dikuadratkan tergantung pada ada atau tidaknya hubungan identifikasi dengan entitas ini. Atribut yang dimigrasikan juga dapat menjadi bagian dari kunci alternatif.

Gambar 11. Foreign Key Syntax
Role Name Syntax
Nama peran, seperti nama domain (atribut), adalah frasa kata benda. Nama peran diikuti oleh nama atribut yang dimigrasikan, dipisahkan oleh tanda titik. Lihat Gambar 12.

Gambar 12. Role Name Syntax
Foreign Key Rules
1.      Setiap entitas harus mengandung sekumpulan atribut kunci asing untuk setiap koneksi atau hubungan kategorisasi tertentu di mana itu adalah entitas anak atau kategori. Atribut yang diberikan dapat menjadi anggota dari beberapa set tersebut. Selanjutnya, jumlah atribut dalam himpunan atribut kunci asing harus sama dengan jumlah atribut kunci primer induk atau entitas generik.
2.      Kunci utama entitas generik harus dimigrasikan sebagai kunci utama untuk setiap entitas kategori.
3.      Entitas anak tidak boleh mengandung dua kunci asing penuh yang mengidentifikasi instance yang sama dari leluhur yang sama (induk atau entitas generik) untuk setiap instance anak kecuali kunci asing ini dikontribusikan melalui jalur hubungan terpisah yang berisi satu atau lebih entitas intervensi antara leluhur dan anak.
4.      Setiap atribut yang dimigrasikan dari entitas anak atau kategori harus mewakili atribut dalam kunci utama dari induk atau entitas generik terkait. Sebaliknya, setiap atribut kunci utama dari induk atau entitas generik harus merupakan atribut yang dimigrasi dalam entitas anak atau kategori terkait.
5.      Setiap nama peran yang ditetapkan untuk atribut yang dimigrasi harus unik dan makna yang sama harus selalu berlaku untuk nama yang sama. Lebih jauh lagi, makna yang sama tidak dapat berlaku untuk nama yang berbeda kecuali nama tersebut alias.
6.      Atribut yang dimigrasikan dapat menjadi bagian dari lebih dari satu kunci asing asalkan atribut selalu memiliki nilai yang sama untuk kunci-kunci asing ini dalam setiap instance entitas. Nama peran dapat ditetapkan untuk atribut yang dimigrasi ini.
7.      Setiap atribut kunci asing harus merujuk satu dan hanya satu dari atribut kunci utama dari induk. Atribut A mereferensikan atribut B lainnya jika A = B atau A adalah sub-tipe langsung atau tidak langsung dari B. Atribut A dianggap sebagai sub-tipe B jika A adalah alias untuk C dan C adalah sub-tipe dari B, atau A adalah sub-tipe C dan C adalah alias untuk B.
View Levels
Ada tiga tingkatan skema konseptual pemodelan IDEF1X; entitas-hubungan (ER), berbasis-kunci (KB), dan atribut lengkap (FA). Mereka berbeda dalam sintaks dan semantik yang memungkinkan masing-masing. Perbedaan utama adalah:
1.      Tampilan ER tidak menentukan kunci.
2.      Tampilan KB menentukan kunci dan beberapa atribut non-kunci.
3.      Tampilan FA menentukan kunci dan semua atribut non-kunci.
Pandangan skema tingkat IDEF1X memberikan informasi struktural yang diperlukan untuk merancang database yang efisien untuk sistem fisik. Sintaksis grafis IDEF1X sering digunakan secara informal untuk menggambarkan struktur basis data fisik. Ini bisa sangat berguna dalam merekayasa ulang sistem saat ini, dan menyediakan metode untuk memperoleh definisi data terintegrasi dari sumber daya data yang ada.
View Level Semantics
Pandangan-hubungan harus mengandung entitas dan hubungan, dapat mengandung atribut, dan tidak boleh mengandung kunci utama, alternatif, atau asing. Karena tampilan ER tidak menentukan kunci apa pun, entitas mereka tidak perlu dibedakan sebagai pengidentifikasi-tergantung atau pengidentifikasi-independen, dan hubungan koneksi mereka tidak perlu dibedakan sebagai pengidentifikasi atau non-pengidentifikasi. Tampilan ER dapat berisi hubungan kategorisasi, tetapi atribut diskriminator adalah opsional. Tampilan ER juga dapat berisi hubungan tidak spesifik.
Tampilan berbasis kunci harus mengandung entitas, hubungan, kunci primer, dan kunci asing. Entitas harus dibedakan sebagai pengidentifikasi-tergantung atau pengidentifikasi-independen, dan hubungan koneksi harus dibedakan sebagai pengidentifikasi atau non-pengidentifikasi. Kardinalitas induk untuk setiap hubungan yang tidak mengidentifikasi harus ditetapkan sebagai wajib atau opsional. Setiap gugus kategori harus memiliki atribut diskriminator. Hubungan non-spesifik dilarang. Setiap entitas harus mengandung kunci utama dan, jika memiliki kendala keunikan tambahan, kunci alternatif untuk setiap kendala. Setiap entitas harus berisi kunci asing untuk setiap koneksi atau hubungan kategorisasi di mana itu adalah entitas anak atau kategori. Tampilan KB juga dapat berisi atribut non-kunci.
Tampilan yang dikaitkan sepenuhnya memiliki persyaratan yang sama dengan tampilan berbasis kunci. Selain itu, mereka harus mengandung semua atribut non-kunci yang relevan dengan subjek tampilan.
View Level Syntax
Dalam tampilan hubungan entitas, hubungan koneksi ditampilkan sebagai garis solid atau putus-putus. Ketergantungan identifikasi, bagaimanapun, dibiarkan tidak ditentukan. Kotak entitas tidak termasuk garis horizontal yang biasanya memisahkan kunci primer dari atribut non-kunci. Jika tidak ada atribut diskriminator yang telah diidentifikasi untuk cluster kategori, maka tidak ada nama yang muncul dengan lingkaran.
Dalam tampilan berbasis kunci dan sepenuhnya dikaitkan, kotak entitas memiliki sudut persegi atau bulat, tergantung pada apakah mereka pengidentifikasi-independen atau pengidentifikasi-tergantung, dan hubungan koneksi digambarkan sebagai garis solid atau putus-putus, tergantung pada apakah mereka mengidentifikasi atau tidak -mengidentifikasi. Setiap kotak entitas memiliki garis horizontal untuk memisahkan kunci utama dari atribut non-kunci. Nama atribut diskriminator (jika ada) ditempatkan dengan lingkaran untuk setiap kategori diskriminator.
View Level Rules
Beberapa aturan yang dijelaskan di bagian sebelumnya tidak berlaku untuk semua tingkat tampilan. Pengecualian berikut dibuat untuk tampilan tingkat ER.
1.      Entitas tidak perlu memiliki atribut yang ditentukan.
2.      Entitas tidak memiliki kunci primer atau alternatif yang ditentukan.
3.      Tidak ada entitas yang memiliki atribut yang dimigrasi (mis., Entitas tidak memiliki kunci asing).
4.      Entitas tidak perlu dibedakan sebagai pengidentifikasi-independen atau pengenal-tergantung. Entitas kategori dianggap sebagai entitas dependen.
5.      Kardinalitas orang tua (satu, atau nol atau satu) tidak ditentukan dalam hubungan koneksi.
6.      Hubungan tidak harus dibedakan sebagai mengidentifikasi atau tidak mengidentifikasi.
Tabel berikut menyediakan ringkasan tingkat tampilan IDEF1X:

Tabel 1. View Levels and Content
View Presentation
Definisi sintaksis bahasa IDEF1X mencirikan set lengkap konstruksi IDEF1X dan penggunaannya. Namun ini tidak menghalangi “bersembunyi” atau secara opsional menghilangkan konstruksi tertentu untuk memungkinkan presentasi alternatif tampilan IDEF1X. Sering kali ini dilakukan untuk "menyembunyikan" detail yang tidak diperlukan untuk diskusi tertentu, atau untuk mengabstraksikan suatu pandangan untuk memungkinkan pandangan yang lebih luas. Contoh beberapa konstruksi yang mungkin bisa "disembunyikan" mungkin:
·         Entity Numbers
·         Attributes
·         Keys
·         Migrated Keys
·         Role Names
·         Relationship Names
·         Cardinality Specifications
·         Category Discriminators
·         Alternate Key Suffixes
·         Note Identifiers
Bentuk presentasi alternatif ini berbeda dari pandangan “Hanya Untuk Eksposisi” (FEO), di mana semua aturan sintaksis dan semantik yang berlaku masih harus ditegakkan. Contoh presentasi alternatif mungkin menyajikan tampilan yang sepenuhnya dikaitkan, tetapi hanya menunjukkan entitas dan hubungan mereka, untuk memungkinkan tampilan ditinjau dari perspektif UGD.
Glossary
Setiap model IDEF1X harus disertai dengan definisi semua tampilan, entitas, dan domain (atribut). Definisi disimpan dalam glosarium umum untuk semua model dalam konteks tujuan dan ruang lingkup yang dinyatakan.
Untuk setiap tampilan, entitas, dan domain (atribut), glosarium berisi elemen-elemen berikut:
·         Nama> Nama adalah nama unik, didefinisikan sesuai dengan konvensi leksikal IDEF1X. Nama harus bermakna, dan harus bersifat deskriptif. Singkatan dan akronim diizinkan.
·         Deskripsi> Ini adalah deskripsi deklaratif tunggal dari pemahaman umum tentang entitas atau domain (atribut), atau deskripsi tekstual dari konten tampilan. Untuk entitas dan domain (atribut), deskripsi harus berlaku untuk semua penggunaan entitas atau domain (atribut) terkait. Untuk domain yang diketik, referensi ke superclass harus disertakan.
·         Alias> Ini adalah daftar nama lain tempat entitas atau domain (atribut) diketahui. Deskripsi yang terkait dengan entitas atau domain (atribut) harus berlaku dengan tepat dan tepat untuk setiap alias dalam daftar. Nama yang dimodifikasi untuk mendukung otomatisasi komputer dapat didaftar sebagai alias. Alias tidak diizinkan untuk dilihat.
·         Informasi Tambahan> Secara opsional, informasi tambahan mengenai tampilan, entitas, atau domain (atribut) dapat disediakan, seperti nama penulis, tanggal pembuatan, tanggal modifikasi terakhir, dll. Untuk tampilan, informasi ini mungkin juga termasuk level (ER, berbasis kunci, atribut lengkap, dll.), status penyelesaian atau peninjauan, dan sebagainya. Untuk domain (atribut), informasi ini mungkin termasuk tipe data, aturan domain, atau spesifikasi superclass.
Model Notes
Catatan yang bersifat umum, dan catatan bahwa mendokumentasikan kendala spesifik merupakan bagian integral dari model. Catatan ini dapat menyertai tampilan grafik.
Notes that document specific constraints are also represented in the view graphics by the symbol “(n)” placed adjacent to the impacted object (entity, relationship, or attribute). The “n“ in “(n)” is the number of the note in which the text of the constraint is documented.
Catatan yang bersifat umum diwakili dalam grafik tampilan dengan simbol “(n)” yang ditempatkan berdekatan dengan objek yang terpengaruh (entitas, hubungan, atribut, atau nama tampilan). "N" dalam "(n)" adalah jumlah catatan di mana teks catatan didokumentasikan.
Catatan bahwa mendokumentasikan kendala spesifik juga diwakili dalam tampilan grafik oleh simbol "(n)" yang ditempatkan berdekatan dengan objek yang terkena dampak (entitas, hubungan, atau atribut). "N" dalam "(n)" adalah jumlah catatan di mana teks kendala didokumentasikan. Beberapa jenis asersi atau kendala dapat didokumentasikan. Pernyataan jalan adalah salah satu jenisnya. Penegasan jalur melibatkan dua atau lebih jalur antara suatu entitas dan salah satu leluhurnya. Setiap jalur adalah hubungan khusus atau hubungan kategorisasi atau serangkaian hubungan di mana anak dalam satu adalah orang tua di jalur berikutnya. Misalnya, jika entitas DEPARTMENT memiliki dua entitas anak, PROYEK dan KARYAWAN, dan mereka memiliki anak yang sama yang disebut PROJECT-ASSIGNMENT, maka ada dua jalur antara DEPARTMENT dan PROJECT-ASSIGNMENT, satu melalui PROYEK dan satu melalui EMPLOYEE. Penegasan jalur menjelaskan batasan pada instance entitas leluhur (mis., DEPARTEMEN) yang dapat terkait dengan setiap instance dari entitas turunan (mis., PENUGASAN PROYEK). Penegasan jalur dapat menyatakan bahwa turunan turunan harus terkait dengan turunan leluhur yang sama melalui setiap jalur, atau bahwa turunan harus terkait dengan turunan leluhur yang berbeda melalui setiap jalur. Dalam contoh di atas, pernyataan jalur mungkin menyatakan bahwa "karyawan hanya dapat ditugaskan untuk proyek-proyek yang menjadi bagian dari departemen tempat mereka bekerja", mis., Contoh PROJECT-ASSIGNMENT harus terkait dengan instance DEPARTMENT yang sama melalui kedua jalur. Di sisi lain, pernyataan jalur dapat mengatakan “karyawan tidak dapat ditugaskan ke proyek yang menjadi bagian dari departemen tempat mereka bekerja”, yaitu, contoh PROJECT-ASSIGNMENT harus terkait dengan instance DEPARTMENT yang berbeda melalui setiap jalur. Kemungkinan ketiga adalah bahwa "karyawan dapat ditugaskan ke proyek-proyek milik departemen mana pun." Karena tidak ada batasan dalam situasi ini, tidak diperlukan penegasan jalur.
Jika tidak ada jalur yang menyertakan hubungan yang tidak mengidentifikasi, maka kunci utama entitas leluhur akan bermigrasi sepanjang jalan ke entitas turunan di sepanjang semua jalur, yang mengakibatkan banyak kemunculan atribut yang dimigrasi dalam turunan. Dalam hal ini, nama peran mungkin diperlukan dalam hubungannya dengan pernyataan jalur. Ada empat kemungkinan situasi.
If none of the paths include a non-identifying relationship, then the primary key of the ancestor entity will migrate all the way to the descendent entity along all paths, resulting in multiple occurrences of the migrated attribute in the descendent. In this case, role names may be needed in conjunction with the path assertion. There are four possible situations.
1.      Contoh leluhur selalu sama. Ini berarti turunan turunan harus terkait dengan turunan leluhur yang sama melalui semua jalur. Dalam situasi ini, tidak menetapkan nama peran, atau menetapkan nama peran yang sama untuk semua kemunculan atribut yang dimigrasikan dalam entitas turunan. Memberikan nama peran yang sama untuk semua kejadian sudah cukup untuk memodelkan pernyataan jalur, sehingga catatan kendala tidak diperlukan.
2.      Contoh leluhur selalu berbeda. Ini berarti turunan turunan harus terkait dengan turunan leluhur yang berbeda melalui setiap jalur. Dalam situasi ini, tetapkan nama peran yang berbeda untuk setiap kemunculan atribut yang dimigrasi dalam turunan, dan tambahkan pernyataan jalur yang menyatakan bahwa nilainya harus berbeda.
3.      Semua contoh leluhur mungkin sama, atau mungkin berbeda. Dalam situasi ini, tetapkan nama peran yang berbeda untuk setiap kemunculan atribut yang dimigrasi dalam turunan, tetapi jangan tambahkan pernyataan jalur. Pernyataan jalan tidak diperlukan dalam kasus ini karena memberikan kemunculan nama peran yang berbeda memungkinkan, tetapi tidak mengharuskan, nilainya berbeda.
4.      Beberapa contoh leluhur mungkin sama, atau mungkin berbeda, dan yang lain harus sama, atau harus berbeda. Dalam hal ini, nyatakan beberapa pernyataan jalur, satu untuk setiap situasi yang dijelaskan di atas dalam a), b), dan c).
Pernyataan yang tidak dapat dibuat menggunakan nama peran dinyatakan dalam catatan. Jenis pernyataan lain mungkin menentukan batasan boolean antara dua atau lebih hubungan. Sebagai contoh, batasan “eksklusif ATAU” menyatakan bahwa untuk instance entitas induk yang diberikan jika satu tipe instance entitas anak ada, maka tipe instance entitas anak kedua tidak akan ada. Namun, jika kedua entitas induk dan anak merujuk pada hal dunia nyata yang sama, maka hubungan kategorisasi potensial ada. Pernyataan kendala Boolean yang tidak melibatkan hubungan kategorisasi dicatat sebagai catatan yang menyertai diagram.
Value assertions are used to specify cases in which attributes of an entity may be null. Penegasan nilai digunakan untuk menentukan kasus-kasus di mana atribut suatu entitas dapat nol.
Model Note Rules
1.      Nomor catatan unik dalam tampilan.
2.      Teks yang sama harus berlaku untuk nomor catatan yang sama jika nomor catatan itu digunakan beberapa kali dalam tampilan.
Lexical Conventions
Konvensi Lexical Bagian ini memberikan aturan untuk membangun nama dan frasa untuk tampilan IDEF1X.
View, Entity, and Domain (Attribute) Names
Konvensi leksikal berikut berlaku untuk tampilan, entitas, dan nama domain (atribut).
1.      Hanya huruf besar dan kecil, karakter alfanumerik, tanda hubung ("-"), garis bawah ("_"), dan spasi ("") diizinkan.
2.      Nama dan label tidak peka huruf besar-kecil, mis., “A” = “a”. Selain itu, simbol pemisah, spasi (""), tanda hubung ("-"), dan garis bawah ("_") dianggap setara.
3.      Nama harus dimulai dengan huruf.
4.      Istilah dalam nama dipisahkan oleh tanda hubung, garis bawah, atau spasi.
5.      Panjang nama tidak boleh melebihi 120 karakter.
Contoh-contoh berikut dari nama entitas mewakili entitas yang sama:
·         Purchase-Order_Line
·         Purchase_Order_LINE
·         purchase order line
Contoh-contoh nama domain (atribut) berikut mewakili domain yang sama:
·         Purchase-Order-Item-QUANTITY
·         purchase_order_item_quantity
·         PURCHASE ORDER ITEM QUANTITY
Contoh nama tampilan berikut mewakili tampilan yang sama:
·         PURCHASING-PROCESS
·         Purchasing_Process
·         purchasing process
Entity Labels
Label entitas dapat berisi nama dan pengidentifikasi. Dalam hal ini, konvensi leksikal berikut berlaku.
1.      Identifier adalah bilangan bulat positif.
2.      Garis miring (“/”) digunakan untuk memisahkan nama dari pengenal.
3.      Pengidentifikasi ditempatkan setelah nama.
Contoh label entitas dengan nama dan pengenal adalah:
·         Pembelian-Pesanan-Barang / 12
Role Name Attribute Labels
Label atribut nama peran berisi nama peran dan nama atribut asli. Konvensi leksikal berikut ini berlaku untuk label nama peran.
1.      Kedua nama atribut dipisahkan oleh tanda titik (“.”).
2.      Spasi tidak diperbolehkan segera sebelum atau segera setelah periode.
3.      Nama peran mendahului periode.
4.      Nama asli atribut mengikuti tanda titik.
5.      Ketika atribut dengan nama peran dimigrasikan ke entitas lain, hanya nama peran yang ditampilkan di entitas anak.
Contoh label atribut nama peran adalah:
·         Component-Part-Identifier.Part-Identifier
Relationship Names and Labels
Konvensi leksikal berikut ini berlaku untuk nama hubungan.
1.      Huruf besar dan huruf kecil karakter alfanumerik diizinkan.
2.      Karakter selain karakter alfanumerik tidak diperbolehkan.
3.      Istilah dalam nama hubungan dipisahkan oleh satu ruang kosong.
4.      Panjang nama tidak boleh melebihi 120 karakter.
5.      Nama hubungan dua arah dipisahkan oleh garis miring ("/").
6.      Label hubungan ditempatkan dengan garis hubungan.
Contoh nama untuk hubungan antara entitas Purchase-Order dan Purchase-Order-Item adalah:
·         Mengizinkan pembelian
Contoh label hubungan dua arah antara entitas Karyawan dan entitas Ayub adalah:
·         Melakukan / ditugaskan untuk
Model Notes
Catatan harus mematuhi konvensi leksikal berikut.
1.      Nomor catatan adalah bilangan bulat positif.
2.      Nomor catatan terlampir di dalam tanda kurung.
3.      Ketika beberapa catatan berlaku untuk istilah yang sama, satu dari dua presentasi alternatif harus digunakan. Entah setiap nomor note harus diapit di dalam tanda kurung, yaitu (1) (2) ... (n), atau semua nomor note harus ditutup dalam satu set tanda kurung, yaitu (1,2, ..., n).
4.      Nomor di dalam tanda kurung berlaku untuk satu not.
5.      Spasi digunakan untuk memisahkan teks catatan dari nomor catatan.
6.      Teks catatan dapat menyertakan simbol karakter apa pun.
7.      Nomor catatan ditempatkan setelah label item yang berlaku.
8.      Nomor catatan yang berlaku untuk hubungan pertama dalam label hubungan dua arah ditempatkan sebelum garis miring.
9.      Nomor catatan yang ditempatkan setelah label hubungan dua arah berlaku untuk hubungan setelah slash.
Contoh label hubungan dua arah dengan nomor catatan adalah:
·         Melakukan (5) / ditugaskan ke (6)
Displaying Labels on More Than One Line
Ketika batasan panjang membutuhkan label untuk ditampilkan pada banyak garis, harus jelas mana yang merupakan garis lanjutan dan mana yang merupakan label baru. Simbol penjelasan (mis., Nomor catatan, sufiks kunci asing atau alternatif) disertakan pada baris terakhir label.
Contoh untuk label entitas adalah:
·         Purchase-Order-
Item/12
·         Purchase-Order-Item/
12 (16)
Contoh untuk nama atribut dan atribut dengan nama peran adalah:
·         Purchase-Order-Item-
Unit-Price-Amount (5)
·         Component-Part-Identifier.
Part-Identifier (FK)
Contoh untuk label relationship adalah:
·         Performs /
Is assigned to
·         Performs / Is
assigned to (5)
Cara menggambar dan interpretasi notasi
Modeling Guidelines
Fase Nol - Inisiasi Proyek Model data
IDEF1X harus diuraikan dan didefinisikan dalam batasan dan ambisinya. Pemodel adalah salah satu pengaruh utama dalam pengembangan ruang lingkup model. Bersama-sama, pemodel dan manajer proyek membuka rencana untuk mencapai tujuan Tahap Nol. Tujuan-tujuan ini meliputi:
1.      Definisi proyek - pernyataan umum tentang apa yang harus dilakukan, mengapa, dan bagaimana itu akan dilakukan.
2.      Sumber bahan - rencana untuk pengadaan bahan sumber, termasuk pengindeksan dan pengarsipan.
3.      Konvensi penulis - deklarasi mendasar dari konvensi (metode opsional) dimana penulis memilih untuk membuat dan mengelola model.
Produk dari tujuan ini, ditambah dengan informasi deskriptif dan penjelasan lainnya, menjadi produk dari upaya Fase usaha nol.
Menetapkan Tujuan Pemodelan
Tujuan pemodelan terdiri dari dua pernyataan:
1.      Pernyataan tujuan - pernyataan yang mendefinisikan masalah model, yaitu batas kontekstualnya.
2.      Pernyataan ruang lingkup - pernyataan yang mengungkapkan batas-batas fungsional model.
Salah satu perhatian utama, yang akan dijawab sebagai hasil dari penetapan tujuan pemodelan, adalah kekhawatiran atas referensi kerangka waktu untuk model. Apakah itu akan menjadi model dari kegiatan saat ini (yaitu, model AS-IS) atau apakah itu akan menjadi model apa yang dimaksudkan setelah perubahan di masa depan dibuat (yaitu, model TO-BE)? Deskripsi formal dari domain masalah untuk proyek pemodelan IDEF1X dapat mencakup tinjauan, konstruksi, modifikasi, dan / atau elaborasi satu atau lebih model (aktivitas) IDEF0. Untuk alasan ini, baik pemodel dan manajer proyek harus berpengalaman dalam beberapa tingkat dalam kepenulisan dan penggunaan model IDEF0. Biasanya, model IDEF0 sudah ada, yang dapat berfungsi sebagai dasar untuk masalah domain.
Meskipun maksud di balik pemodelan data adalah untuk membangun pandangan yang tidak bias dari infrastruktur data yang mendasarinya yang mendukung seluruh perusahaan, penting bagi setiap model untuk memiliki ruang lingkup yang mapan yang membantu mengidentifikasi data spesifik yang menarik. Ruang lingkup ini mungkin terkait dengan tipe pengguna (mis. Pembeli atau insinyur desain) fungsi bisnis (mis. Rilis gambar teknik atau penjadwalan pesanan toko) atau tipe data (mis. Data definisi produk geometris atau data keuangan). Pernyataan ruang lingkup bersama dengan pernyataan tujuan mendefinisikan tujuan pemodelan. Berikut ini adalah contoh tujuan pemodelan:
"Tujuan dari model ini adalah untuk mendefinisikan data saat ini (AS-IS) yang digunakan oleh penyelia sel manufaktur untuk memproduksi dan menguji bagian-bagian pesawat komposit."
Meskipun ruang lingkup mungkin terbatas pada satu jenis pengguna, pengguna lain harus terlibat dalam proses pemodelan untuk memastikan pengembangan pandangan yang tidak bias.
Mengembangkan Rencana Pemodelan
Rencana pemodelan menguraikan tugas-tugas yang harus diselesaikan dan urutan di mana mereka harus diselesaikan. Ini ditata sesuai dengan tugas keseluruhan dari upaya pemodelan:
1.      Perencanaan proyek
2.      Pengumpulan data
3.      Definisi entitas
4.      Definisi hubungan
5.      Definisi atribut kunci
6.      Populasi atribut bukan kunci
7.      Validasi model
8.      Tinjauan penerimaan
Rencana pemodelan berfungsi sebagai dasar untuk menetapkan tugas, menjadwalkan tonggak, dan memperkirakan biaya untuk upaya pemodelan.
Mengatur Tim
Nilai suatu model diukur bukan terhadap norma absolut, tetapi dalam hal penerimaannya terhadap para ahli dan orang awam di dalam komunitas tempat ia dibangun. Ini dicapai melalui dua mekanisme. Pertama, tinjauan konstan oleh para ahli dari model yang berkembang memberikan ukuran validitas model tersebut dalam lingkungan tertentu dari para ahli tersebut. Kedua, tinjauan model secara berkala oleh komite ahli dan orang awam memberikan konsensus "perusahaan" untuk model tersebut. Selama proses pemodelan, tidak jarang menemukan ketidakkonsistenan dalam cara berbagai departemen melakukan bisnis. Ketidakkonsistenan ini harus diselesaikan untuk menghasilkan model data yang mewakili perusahaan dengan cara yang dapat diterima dan terintegrasi.
Sedapat mungkin, pembangun model harus bertanggung jawab atas apa yang dikatakan model. Tidak ada yang dianggap telah menjadi imajinasi pembaca model. Pembaca juga tidak dapat menarik kesimpulan di luar ruang lingkup pernyataan model. Ini memaksa pemodel untuk mempertimbangkan setiap bagian data yang ditambahkan ke model dengan hati-hati, sehingga tidak diperlukan imajinasi dalam interpretasi model.
Organisasi tim dibangun untuk mendukung prinsip-prinsip dasar ini dan untuk menyediakan kontrol proyek yang diperlukan. Organisasi tim IDEF1X memiliki lima peran utama:
1.      Manajer proyek
2.      Pemodel
3.      Sumber informasi
4.      Ahli materi pelajaran
5.      Komite peninjau penerimaan
Tujuan dari penugasan peran, terlepas dari penerima tugas, adalah penentuan tanggung jawab.
Masing-masing peran ini didefinisikan pada halaman-halaman berikutnya.
Satu orang dapat melayani dalam lebih dari satu kapasitas dalam tim, tetapi adalah bijaksana untuk mengingat bahwa jika ada titik pandang yang tidak cukup dipertimbangkan ketika membangun model, model dapat mewakili perspektif yang sangat sempit. Mungkin hanya sebagian yang melayani untuk mencapai tujuan proyek pemodelan.
Dalam kasus manajer proyek dan pemodel, harus ada individu, atau kepala sekolah, individu yang memenuhi peran. Meskipun itu adalah tujuan akhir pemodel untuk memiliki model yang disetujui oleh komite peninjau, pemodel melaporkan ke manajer proyek, bukan komite peninjau. Dengan cara ini, kepentingan yang bertentangan dari pemodel, komite peninjau, dan manajer proyek dipisahkan. Manajer proyek selalu ditempatkan di posisi kontrol, tetapi berbagai diskusi teknis dan persetujuan secara otomatis didelegasikan kepada peserta yang memenuhi syarat. Gambar 13 mengilustrasikan organisasi proyek fungsional, dengan manajer proyek sebagai inti dari semua kegiatan proyek.

Gambar 13. Team Organization
Peran Project Manager
Manajer proyek adalah orang yang diidentifikasi memiliki kendali administratif atas proyek pemodelan. Manajer proyek melakukan empat fungsi penting dalam upaya pemodelan.
Pertama-tama, manajer proyek memilih pemodel. Sebagai bagian utama dari fungsi ini, manajer proyek dan pemodel harus mencapai kesepakatan tentang aturan dasar yang harus diikuti dalam upaya pemodelan. Ini termasuk penggunaan metodologi ini, tingkat kontrol yang diharapkan oleh manajer proyek untuk dipraktikkan oleh pemodel, dan ruang lingkup dan orientasi model yang akan dikembangkan.
Selanjutnya, manajer proyek memilih para ahli yang pengetahuan dan pemahaman pemodelnya akan menarik untuk validasi model yang berkembang. Validasi, seperti yang dibahas di bawah di bawah Pakar, berarti persetujuan bahwa model tersebut dapat diterima mencerminkan subjek yang dimodelkan. Para ahli akan diberikan bagian dari model dan diminta untuk meninjau dan berkomentar berdasarkan pengetahuan khusus mereka. Jelas, lebih banyak waktu seorang ahli akan diserap dalam upaya pemodelan daripada waktu yang akan kami sisihkan untuk sumber informasi dasar. Daftar awal para ahli ditetapkan selama Fase Nol, tetapi akan ditinjau dan direvisi sepanjang upaya pemodelan sesuai kebutuhan.
Akhirnya, manajer proyek membentuk dan membentuk komite peninjauan penerimaan. Komite ini, di bawah pimpinan manajer proyek, bertemu secara berkala untuk mempertimbangkan masalah substansi yang memerlukan arbitrase dan untuk meninjau bagian-bagian dari model untuk penerimaan formal. Manajer proyek duduk di komite sebagai ketua yang tidak memberikan suara, sehingga menyediakan hubungan yang diperlukan antara pemodel dan komite. Meskipun pemodel bukanlah anggota komite, manajer proyek akan sering mengundang pemodel untuk menghadiri pertemuan komite untuk memberikan informasi latar belakang atau untuk menjelaskan poin-poin teknis yang sulit. Pertemuan pertama komite diadakan selama Fase Nol, dan setelah itu atas kebijakan manajer proyek.
Peran Modeler
Pemodel mencatat model berdasarkan bahan sumber yang ia dapat kumpulkan. Ini adalah fungsi pemodel untuk menerapkan teknik pemodelan pada masalah yang diajukan oleh manajer proyek. Pemodel melakukan empat fungsi utama: pengumpulan data sumber, pendidikan dan pelatihan, perekaman model, dan kontrol model. Pemodel adalah pusat clearing untuk informasi metodologi pemodelan dan informasi tentang model itu sendiri.
Sebelum fungsi utama pemodel dimulai, pemodel dan manajer proyek mempelajari dan menetapkan ruang lingkup upaya pemodelan. Pemodel kemudian menguraikan rencana proyek, mis., Tugas-tugas yang diperlukan untuk mencapai tujuan yang dinyatakan. Manajer proyek memberikan pemodel dengan daftar sumber informasi dan daftar ahli yang menjadi sandaran pemodel. Pemodel harus memastikan bahwa jalur komunikasi yang diperlukan ditetapkan dengan semua peserta.
Sumber data dikumpulkan oleh pemodel dari berbagai sumber yang diidentifikasi oleh manajer proyek. Sifat data ini akan sangat tergantung pada fase pemodelan yang dilakukan. Baik orang dan dokumen akan berfungsi sebagai sumber informasi selama upaya pemodelan. Pemodel harus sangat menyadari bahwa setiap bagian dari data sumber mewakili pandangan tertentu dari data di perusahaan. Setiap produsen dan setiap pengguna data memiliki pandangan yang berbeda tentang data tersebut. Pemodel berusaha untuk melihat, melalui mata sumber, makna dan struktur data yang mendasarinya. Setiap sumber memberikan perspektif, pandangan tentang data yang dicari. Dengan menggabungkan pandangan-pandangan ini, dengan membandingkan dan membedakan berbagai perspektif, pemodel mengembangkan citra realitas yang mendasarinya. Setiap dokumen dapat dilihat sebagai implementasi sistem mikrokosmik, memenuhi aturan model data yang mendasarinya. Pemodel berusaha untuk menangkap semua aturan ini dan mewakilinya dengan cara yang dapat dibaca, dipahami, dan disetujui oleh para ahli dan orang awam yang terinformasi.
Fungsi kedua pemodel adalah untuk memberikan bantuan dengan teknik pemodelan kepada mereka yang mungkin membutuhkannya. Ini umumnya akan jatuh ke dalam tiga kategori: orientasi umum untuk anggota komite peninjau, sumber, dan beberapa ahli; model keterampilan pembaca untuk beberapa sumber dan pakar; dan keterampilan pemodelan untuk beberapa ahli dan pemodel, sesuai kebutuhan.
Fungsi ketiga adalah merekam model. Pemodel merekam model data melalui deskripsi tekstual dan grafik.
Pemodel juga mengontrol pengembangan model. File-file sumber informasi turunan dipelihara untuk menyediakan cadangan yang sesuai untuk keputusan yang dibuat oleh pemodel, dan untuk memungkinkan catatan partisipasi. Catatan partisipasi ini memberikan kepada pemodel suatu indikasi sejauh mana cakupan yang diantisipasi sedang dicakup. Dengan mengetahui siapa yang telah memberikan informasi di bidang apa, dan kualitas interaksi tersebut, pemodel dapat memperkirakan sejauh mana upaya pemodelan saat ini telah efektif dalam memenuhi tujuan awal.
Pemodel juga bertanggung jawab untuk mengatur secara berkala konten model ke dalam sejumlah kit pembaca untuk didistribusikan kepada pengulas. Kit pembaca adalah kumpulan informasi tentang model, yang diorganisasikan untuk memfasilitasi ulasannya dan pengumpulan komentar dari para pakar informasi.
Peran Source
Sumber informasi untuk model IDEF1X berasal dari setiap kuartal dalam perusahaan. Sumber-sumber ini seringkali adalah orang-orang yang memiliki pengetahuan khusus tentang manajemen atau operasi dari beberapa proses bisnis dan yang kontaknya dengan model mungkin terbatas pada beberapa menit waktu wawancara singkat. Namun sumber-sumber ini merupakan jantung dari proses pemodelan. Kontribusi mereka dimodelkan, dan persepsi mereka memberi pemodel wawasan yang dibutuhkan untuk membangun model yang valid dan berguna. Sumber harus dicari dan digunakan untuk keuntungan terbaik di mana pun mereka ditemukan.
Manajer proyek mengidentifikasi sumber-sumber informasi yang mungkin efektif, berdasarkan pernyataan kebutuhan pemodel. Ketika upaya pemodelan berlangsung, perubahan kebutuhan dan daftar sumber harus direvisi. Sedangkan pemodel harus berhati-hati untuk memperhitungkan informasi yang diberikan oleh masing-masing sumber, baik pemodel dan sumber harus menyadari bahwa setiap kontribusi tertentu harus bias. Setiap sumber memandang dunia sedikit berbeda, dan merupakan tanggung jawab pemodel untuk memilah berbagai pandangan ini. Ini terutama berlaku untuk dokumen sumber.
Dokumen mencatat keadaan sebagian kecil dari perusahaan di beberapa titik waktu. Namun, informasi pada dokumen diatur untuk kenyamanan penggunanya, dan jarang secara langsung mencerminkan struktur data yang mendasarinya. Redundansi data adalah contoh paling umum dari ini, tetapi kemunculan data kebetulan pada dokumen juga merupakan sumber kebingungan yang sering dan membuat frustrasi. Dokumen adalah sumber informasi yang berharga untuk model, tetapi mereka membutuhkan banyak interpretasi, pemahaman, dan bukti untuk digunakan secara efektif.
Jika model data sedang dikembangkan untuk mengintegrasikan atau mengganti database yang ada, maka desain database yang ada harus dirujuk sebagai dokumen sumber. Namun, seperti dokumen lainnya, desain database yang ada umumnya tidak mencerminkan struktur data yang mendasarinya dan membutuhkan interpretasi.
Orang yang digunakan sebagai sumber, di sisi lain, seringkali dapat memperluas diri mereka di luar penggunaan langsung informasi mereka untuk memberi tahu pemodel bagaimana informasi itu diperoleh, ditafsirkan, atau digunakan. Dengan mengajukan pertanyaan yang tepat, pemodel dapat menggunakan informasi ini untuk membantu dalam memahami bagaimana persepsi satu sumber dapat berhubungan dengan yang dari sumber lain.
Peran Ahli (Expert)
Seorang ahli adalah orang yang ditunjuk oleh manajer proyek yang memiliki pengetahuan khusus tentang beberapa aspek dari area manufaktur yang dimodelkan, dan yang keahliannya akan memungkinkan komentar kritis yang berharga dari model yang maju. Dampak yang dapat diberikan para ahli yang tepat pada upaya pemodelan tidak dapat terlalu ditekankan. Baik pemodel dan manajer proyek harus secara serius mempertimbangkan pemilihan masing-masing ahli.
Para ahli diminta untuk meninjau secara kritis bagian-bagian dari model yang berkembang. Ini dicapai melalui latihan sejumlah siklus validasi, dan dengan menggunakan kit pembaca. Kit ini memberi para ahli koleksi informasi terkait yang disajikan untuk menceritakan sebuah kisah. Dengan cara ini, ahli diberikan informasi dalam bentuk yang mudah dicerna dan ditantang untuk mengisi kekosongan atau melengkapi cerita. Meskipun kit ini sebagian besar didasarkan pada interpretasi modeler informasi dari sumber informasi, komentar para ahli juga diharapkan untuk menyediakan bahan sumber berkualitas tinggi untuk penyempurnaan model. Keahlian khusus dari orang-orang ini membuat mereka memiliki kualifikasi unik untuk membantu pemodel dalam membangun dan menyempurnakan model. Pemodel harus mengambil setiap kesempatan untuk meminta masukan seperti itu, dan inilah mengapa paket informasi harus menghadirkan masalah yang jelas dan jelas kepada ahli untuk dipecahkan relatif terhadap upaya pemodelan.
Pekerjaan utama ahli adalah memvalidasi model. Validasi pakar adalah sarana utama untuk mencapai konsensus para pakar yang terinformasi. Artinya, model yang valid adalah yang disetujui oleh para ahli yang diberi tahu tentang model tersebut. Perhatikan bahwa model tidak perlu "benar" agar valid. Jika mayoritas ahli di bidang setuju bahwa model tepat dan sepenuhnya mewakili bidang yang menjadi perhatian, maka model dianggap valid. Pendapat yang berbeda selalu dicatat, dan diasumsikan oleh disiplin bahwa model tidak valid sampai dibuktikan sebaliknya. Inilah sebabnya mengapa partisipasi pakar sangat penting untuk upaya pemodelan. Ketika modeler pertama kali membangun sebagian dari model, dia berkata, "Saya telah meninjau fakta-fakta dan menyimpulkan yang berikut ..." Ketika bagian itu diserahkan kepada para ahli untuk ditinjau, dia bertanya, "Apakah saya benar?" Komentar pakar kemudian dipertimbangkan dalam merevisi bagian model yang tidak disetujui oleh para ahli, selalu mengingat bahwa suatu konsensus sedang dicari.
Para ahli, lebih dari peserta non-pemodelan lainnya, membutuhkan pelatihan agar efektif. Bahkan, salah satu tanggung jawab pemodel adalah untuk memastikan bahwa para ahli memiliki pemahaman yang memadai tentang metodologi dan proses pemodelan. Pada prinsipnya, para ahli memerlukan keterampilan pembaca model yang baik, tetapi mungkin akan membantu untuk melatih seorang ahli dalam beberapa dasar-dasar kepenulisan model. Dengan memberikan para ahli pemahaman dasar tentang pemodelan, proyek dijamin mendapat masukan yang berguna dari para ahli tersebut. Selanjutnya, sifat bertahap, sifat tambahan dari proses pemodelan menyajikan para ahli dengan metodologi pemodelan dalam dosis kecil. Ini cenderung meningkatkan kemampuan ahli untuk memahami dan berkontribusi pada upaya pemodelan.
Peran Komite Peninjau Penerimaan
Komite peninjauan penerimaan terdiri dari para ahli dan orang awam yang terinformasi di bidang yang ditangani oleh upaya pemodelan. Manajer proyek membentuk komite dan duduk sebagai ketuanya. Merupakan fungsi komite peninjau untuk memberikan panduan dan arbitrasi dalam upaya pemodelan, dan untuk memberikan penilaian akhir atas produk akhir dari upaya: model data IDEF1X. Karena model ini adalah salah satu bagian dari serangkaian acara yang kompleks untuk menentukan dan mengimplementasikan peningkatan sistematis dalam produktivitas perusahaan, penting bagi komite untuk menyertakan perwakilan yang cukup dari penyedia, pengolah, dan pengguna akhir data yang diwakili. Sangat sering, ini berarti perencana kebijakan dan pakar pemrosesan data akan dimasukkan dalam komite. Orang-orang ini terutama peduli dengan kegunaan akhirnya yang model akan diletakkan. Lebih lanjut, mungkin menguntungkan untuk melibatkan para ahli dari area bisnis di luar, tetapi terkait dengan, area yang diteliti. Para ahli ini sering dapat berkontribusi wawasan berharga tentang bagaimana model data akan mempengaruhi, atau dipengaruhi oleh, pekerjaan yang sedang berlangsung di bidang lain.
Tidak jarang bagi mereka yang bertindak sebagai pakar juga bertindak sebagai anggota komite peninjau. Tidak ada konflik kepentingan, yang seharusnya diantisipasi. Seorang ahli sering kali hanya terpapar pada bagian terbatas dari model pada berbagai tahap menengah. Komite peninjau, sebaliknya, harus memberikan penilaian pada seluruh model. Adalah jauh lebih jarang bagi individu yang melayani dalam peran sumber untuk juga duduk di komite, karena pengetahuan mereka biasanya cukup terbatas dalam cakupan untuk mengecualikan mereka dari kontribusi praktis kepada komite. Akhirnya, tidak disarankan bagi para pemodel untuk duduk di komite, karena konflik kepentingan yang parah jelas terlihat. Lebih lanjut, peran pemodel adalah mencatat model tanpa bias dan peran komite adalah untuk memastikan bahwa model tersebut sebenarnya mewakili perusahaan khusus mereka.
Produk akhir dari segmen ini dari definisi proyek adalah dokumentasi dari tugas khusus yang dibuat oleh manajer proyek untuk memenuhi masing-masing persyaratan peran fungsional dari teknik pemodelan.
Mengumpulkan Material Sumber (Source)
Salah satu masalah pertama yang dihadapi pemodel adalah menentukan jenis bahan apa yang perlu dikumpulkan, dan dari sumber apa harus dikumpulkan. Tidak jarang, ruang lingkup dan konteks model IDEF1X akan ditentukan berdasarkan analisis model fungsi IDEF0. Setelah analisis fungsi dan saluran pipa antara fungsi selesai, fungsi target dalam perusahaan yang diwakili oleh model fungsi dapat diidentifikasi. Node fungsi target adalah node yang mewakili konsentrasi informasi yang digunakan, yang mewakili domain masalah.
Setelah area fungsional target telah diidentifikasi dan kategori informasi utama yang dipilih, individu dalam fungsi dapat dipilih untuk berpartisipasi dalam proses pengumpulan data. Pengumpulan data ini dapat dilakukan dengan beberapa cara, termasuk wawancara dengan individu berpengetahuan; pengamatan kegiatan, evaluasi dokumen, kebijakan dan prosedur, dan model-model informasi spesifik aplikasi, dll. Ini membutuhkan penerjemahan node fungsi target menjadi peserta pemodelan yang setara atau berkontribusi. Setelah kelompok yang berpartisipasi dalam fungsi target telah diidentifikasi, manajer proyek dapat melanjutkan untuk mengidentifikasi individu atau area spesifik yang dapat diamati yang dapat digunakan sebagai sumber bahan untuk model.
Materi sumber dapat berupa berbagai bentuk dan mungkin tersebar luas di seluruh organisasi. Bahan sumber dapat meliputi:
1.      Hasil wawancara
2.      Hasil pengamatan
3.      Kebijakan dan prosedur
4.      Output dari sistem yang ada (laporan dan layar)
5.      Input ke sistem yang ada (formulir dan layar entri data)
6.      Spesifikasi database / file untuk sistem yang ada
Terlepas dari metode yang digunakan, tujuan pemodel pada titik ini adalah untuk membuat rencana pengumpulan dokumentasi yang representatif yang mencerminkan informasi yang berkaitan dengan tujuan dan sudut pandang model. Setelah dikumpulkan, setiap bagian dari dokumentasi ini harus ditandai sedemikian rupa sehingga dapat dilacak ke sumbernya. Dokumentasi ini, bersama dengan dokumentasi tambahan yang ditemukan melalui jalannya pemodelan, akan terus-menerus dirujuk dalam berbagai fase pengembangan model. Pemodel akan mempelajari dan mencari bahan sumber yang memberikan kredibilitas pada karakteristik struktural dasar model dan makna data yang diwakili.
Seperti dibahas dalam Bagian A2, tujuan pemodelan data adalah untuk menentukan pandangan perusahaan tunggal yang konsisten dari sumber daya data yang disebut sebagai Skema Konseptual dalam arsitektur ANSI / SPARC. Sumber dokumen, untuk sebagian besar, mewakili Skema Eksternal atau Skema Internal yang harus memetakan ke Skema Konseptual tetapi bias terhadap penggunaan khusus mereka. Laporan pengguna, misalnya, adalah tampilan Skema Eksternal dari data yang dapat berfungsi sebagai dokumentasi sumber. Deskripsi file dan desain basis data mewakili tampilan Skema Internal data dan juga dapat digunakan sebagai dokumentasi sumber. Meskipun struktur data akan sangat disederhanakan melalui proses pemodelan, model data yang dihasilkan harus dipetakan kembali ke Skema Eksternal dan Internal dari mana ia dikembangkan.
Rencana pengumpulan data yang baik adalah sangat penting untuk mencapai tujuan dengan sukses. Rencana pengumpulan data ini harus mencerminkan jenis data apa yang penting, di mana data itu tersedia, dan siapa yang akan menyediakannya.
Adopt Author Conventions
Author Conventions adalah garis lintang yang diberikan kepada pemodel (penulis) untuk membantu dalam pengembangan model, perangkat ulasannya, dan presentasi lainnya. Tujuannya secara khusus untuk peningkatan penyajian materi. Mereka dapat digunakan di mana saja untuk memfasilitasi pemahaman dan apresiasi yang lebih baik dari setiap bagian dari model. Misalnya, konvensi penamaan standar dapat diadopsi untuk entitas dan nama atribut.
Konvensi penulis dapat mengambil berbagai bentuk dan muncul di berbagai tempat. Tetapi aspek terpenting dari semua ini adalah apa yang bukan konvensi penulis.
1. Konvensi penulis bukanlah perpanjangan formal dari teknik ini
2. Konvensi penulis bukan pelanggaran teknik
Konvensi penulis dikembangkan untuk melayani kebutuhan spesifik. Setiap konvensi harus didokumentasikan saat dikembangkan dan dimasukkan dalam dokumentasi Phase Zero yang didistribusikan untuk ditinjau.
Fase Satu – Definisi Entitas
Tujuan Tahap Satu adalah untuk mengidentifikasi dan mendefinisikan entitas yang termasuk dalam domain masalah yang dimodelkan. Langkah pertama dalam proses ini adalah identifikasi entitas.
Mengidentifikasi Entitas
"Entitas" dalam konteks Model IDEF1X mewakili serangkaian "hal" yang memiliki data yang terkait dengannya, di mana, "benda" dapat berupa individu, zat fisik, peristiwa, akta, ide, dan gagasan, titik, tempat, dll. Anggota himpunan yang diwakili oleh entitas memiliki himpunan atribut atau karakteristik yang sama. Misalnya, semua anggota himpunan karyawan memiliki nomor karyawan, nama, dan atribut umum lainnya. Seorang anggota individu dari suatu himpunan entitas disebut sebagai instance dari entitas tersebut. Misalnya, karyawan bernama Jerry dengan nomor karyawan 789 adalah turunan dari entitas EMPLOYEE. Entitas selalu dinamai dengan frasa nomina tunggal dan generik.
Sebagian besar entitas dapat diidentifikasi secara langsung atau tidak langsung dari bahan sumber yang dikumpulkan selama Fase Nol. Jika upaya pemodelan memperluas atau menyempurnakan model data sebelumnya, entitas yang sesuai harus dipilih dari model sebelumnya. Untuk entitas yang sebelumnya tidak didefinisikan, pemodel harus mengidentifikasi terlebih dahulu dalam daftar nama bahan sumber hal-hal yang mewakili entitas yang berpotensi. Salah satu cara ini dapat disederhanakan adalah untuk mengidentifikasi kemunculan semua kata benda dalam daftar. Misalnya, istilah seperti bagian, kendaraan, mesin, gambar, dll., Pada tahap ini akan dianggap berpotensi sebagai entitas. Metode lain adalah mengidentifikasi istilah-istilah yang diakhiri dengan penggunaan kata "kode" atau "angka," misalnya, nomor bagian, nomor pesanan pembelian, nomor perutean, dll. Frasa atau kata yang mendahului kata "kode" atau "angka" ”Juga dapat dianggap pada tahap ini sebagai entitas yang berpotensi layak. Untuk sisa item dalam daftar ini, pemodel harus bertanya apakah kata tersebut mewakili suatu objek atau hal tentang informasi mana yang diketahui, atau informasi tentang suatu objek atau benda. Barang-barang yang termasuk dalam kategori objek sebagai informasi yang diketahui mungkin juga entitas yang layak.
Entitas dihasilkan dari sintesis instance entitas dasar, yang menjadi anggota entitas. Ini berarti bahwa beberapa jumlah instance entitas, yang semuanya memiliki karakteristik yang sama, direpresentasikan sebagai entitas. Contoh konsep ini ditunjukkan pada Gambar 14. Setiap instance dari entitas adalah anggota dari entitas, masing-masing dengan jenis informasi identifikasi yang sama.
Untuk membantu memisahkan entitas dari non-entitas, pemodel harus mengajukan pertanyaan berikut tentang setiap entitas kandidat:
1.      Bisakah dijelaskan? (Apakah itu memiliki kualitas?)
2.      Apakah ada beberapa contohnya?
3.      Bisakah satu contoh dipisahkan / diidentifikasi dari yang lain?
4.      Apakah ini merujuk atau menggambarkan sesuatu? (Jawaban “ya” menyiratkan atribut daripada entitas.)

Gambar 14. Synthesizing an Entity
Pada akhir analisis ini, pemodel telah mendefinisikan kumpulan entitas awal. Kumpulan ini berisi semua nama entitas dalam konteks model yang dikenal pada saat ini.
Ketika pemodel sedang membangun kumpulan entitas, ia memberikan nama identifikasi terpisah setiap entri dan mencatat referensi ke sumbernya. Dia juga dapat menetapkan nomor identifikasi terpisah sebagai bagian dari nama entitas. Dengan cara ini, ketertelusuran informasi dapat dipertahankan. Integritas kolam tetap utuh, dan pengelolaan kolam relatif mudah. Contoh pool entitas ditunjukkan pada Gambar 15.

Gambar 15. Sample Entity Pool
Dalam semua kemungkinan, tidak semua nama dalam daftar akan tetap sebagai entitas pada akhir Fase Empat. Selain itu, sejumlah entitas baru akan ditambahkan ke daftar ini dan menjadi bagian dari model informasi ketika pemodelan berlangsung dan pemahaman informasi meningkat.
Nama entitas yang ditemukan dalam fase hilir lebih lanjut harus ditambahkan ke kumpulan entitas dan dapat diberi nomor identifikasi unik. Salah satu produk dari upaya Tahap Satu adalah kumpulan entitas. Itu harus up to date untuk tetap layak.
Mendefinisikan Entitas
Produk berikutnya yang muncul dari upaya Tahap Satu adalah awal dari glosarium entitas. Selama Fase Satu, glosarium hanyalah kumpulan definisi entitas.
Komponen definisi entitas meliputi:
1.      NAMA ENTITY Nama entitas adalah nama unik yang dengannya entitas akan dikenali dalam model IDEF1X. Itu harus bersifat deskriptif. Meskipun singkatan dan akronim diizinkan, nama entitas harus bermakna.
2.      DEFINISI ENTITY Ini adalah definisi entitas yang paling umum digunakan dalam perusahaan. Ini tidak dimaksudkan sebagai kamus. Karena makna informasi yang tercermin dalam model khusus untuk sudut pandang model dan konteks model yang didefinisikan dalam Fase Nol, maka tidak ada artinya (jika tidak benar-benar membingungkan) untuk memasukkan definisi di luar lingkup Fase Nol. Namun, mungkin ada sedikit perbedaan konotatif dalam cara entitas didefinisikan, terutama berdasarkan penggunaan kontekstual. Setiap kali ini terjadi, atau setiap kali ada definisi alternatif (yang tidak selalu paling umum dari sudut pandang model), ini juga harus direkam. Terserah pengulas untuk mengidentifikasi definisi apa yang harus dikaitkan dengan istilah yang digunakan untuk mengidentifikasi entitas. Proses definisi Fase Satu adalah mekanisme yang digunakan untuk memaksa evolusi definisi yang diterima secara umum.
3.      ENTITY ALIASES Ini adalah daftar nama-nama lain yang dengannya entitas tersebut dapat diketahui. Satu-satunya aturan yang berkaitan dengan ini adalah bahwa definisi yang terkait dengan nama entitas harus berlaku dengan tepat dan tepat untuk masing-masing alias dalam daftar. Definisi entitas paling mudah diatur dan diselesaikan dengan terlebih dahulu mencari yang membutuhkan jumlah penelitian paling sedikit. Dengan demikian, volume halaman glosarium akan meningkat dalam periode waktu terpendek. Kemudian pemodel dapat melakukan penelitian yang diperlukan untuk sepenuhnya menentukan sisa nama dalam kumpulan. Manajemen waktu dan upaya yang baik diperlukan untuk mengumpulkan dan menentukan informasi akan memastikan bahwa pemodelan berlanjut dengan langkah yang masuk akal.
Fase Kedua– Definisi hubungan (Relationship)
Tujuan Tahap Dua adalah untuk mengidentifikasi dan mendefinisikan hubungan dasar antar entitas. Pada tahap pemodelan ini, beberapa hubungan mungkin tidak spesifik dan akan membutuhkan penyempurnaan tambahan pada fase selanjutnya. Output utama dari Tahap Dua adalah:
1.      Matriks hubungan
2.      Definisi hubungan
3.      Diagram tingkat entitas
Mengidentifikasi Entitas Terkait
"Hubungan" dapat didefinisikan hanya sebagai asosiasi atau koneksi antara dua entitas. Lebih tepatnya, ini disebut "hubungan biner." IDEF1X terbatas pada hubungan biner karena mereka lebih mudah untuk didefinisikan dan dipahami daripada hubungan "n-ary". Mereka juga memiliki representasi grafis langsung. Kerugiannya adalah kecanggungan tertentu dalam merepresentasikan hubungan n-ary. Tetapi tidak ada kehilangan kekuatan karena hubungan n-ary dapat diekspresikan menggunakan n hubungan biner.
Sebuah instance hubungan adalah asosiasi atau koneksi yang bermakna antara dua instance entitas. Sebagai contoh, sebuah instance dari entitas OPERATOR, yang namanya John Doe dan nomor operator adalah 862, ditugaskan ke sebuah instance dari entitas MESIN, yang tipenya adalah bor tekan dan nomor mesin adalah 12678. Hubungan IDEF1X mewakili set jenis instance hubungan yang sama antara dua entitas tertentu. Namun, dua entitas yang sama mungkin memiliki lebih dari satu jenis hubungan.
Tujuan dari model IDEF1X bukan untuk menggambarkan semua hubungan yang mungkin tetapi untuk menentukan interkoneksi antara entitas dalam hal hubungan ketergantungan ketergantungan (orang tua-anak). Yaitu, hubungan antara tipe entitas induk dan tipe entitas anak, di mana setiap instance dari orangtua dikaitkan dengan nol, satu, atau lebih instance anak dan setiap instance anak dikaitkan dengan tepat satu instance dari induk. Artinya, keberadaan entitas anak tergantung pada keberadaan entitas induknya. Misalnya, PEMBELI mengeluarkan nol, satu atau lebih PESANAN PEMBELIAN, dan PESAN PEMBELIAN dikeluarkan oleh satu PEMBELI.
Jika entitas induk dan anak mewakili objek dunia nyata yang sama, maka entitas induk adalah entitas generik dan anak adalah entitas kategori. Untuk setiap instance dari entitas kategori, selalu ada satu instance dari entitas generik. Untuk setiap instance entitas generik, mungkin ada nol atau satu instance kategori. Sebagai contoh, seorang SALARIED-EMPLOYEE adalah KARYAWAN. Seorang KARYAWAN mungkin atau mungkin bukan SALARIED-EMPLOYEE. Beberapa entitas kategori dapat dikaitkan dengan entitas generik dalam cluster kategorisasi tetapi hanya satu kategori yang harus berlaku untuk instance tertentu dari entitas generik. Sebagai contoh, sebuah cluster dapat digunakan untuk mewakili fakta bahwa suatu EMPLOYEE dapat berupa SALARIEDEMPLOYEE atau HOURLY-EMPLOYEE, tetapi tidak keduanya.
Dalam pengembangan awal model, mungkin tidak mungkin untuk mewakili semua hubungan sebagai hubungan orang tua-anak atau kategorisasi. Oleh karena itu, dalam Fase Dua hubungan non-spesifik dapat ditentukan. Hubungan nonspesifik mengambil bentuk umum dari nol, satu, atau lebih ke nol, satu, atau lebih (N: M). Entitas tidak bergantung pada yang lain untuk keberadaannya.
Langkah pertama dalam Fase Dua adalah mengidentifikasi hubungan yang diamati antara anggota berbagai entitas. Tugas ini mungkin memerlukan pengembangan matriks hubungan seperti yang ditunjukkan pada Gambar 16. Matriks hubungan hanyalah array dua dimensi, yang memiliki sumbu horizontal dan vertikal. Satu set faktor yang telah ditentukan (dalam hal ini semua entitas) dicatat sepanjang salah satu sumbu, dan set faktor kedua (dalam hal ini, juga semua entitas) dicatat sepanjang sumbu lainnya. "X" ditempatkan di titik berpotongan di mana salah satu dari dua sumbu bertemu digunakan untuk menunjukkan kemungkinan hubungan antara entitas yang terlibat. Pada titik ini, sifat hubungan itu tidak penting; fakta bahwa suatu hubungan mungkin ada sudah cukup.

Gambar 16. Entity Relationship Matrix Example
Kecenderungan umum untuk pemodel baru adalah menentukan hubungan antar entitas secara berlebihan. Ingat, tujuannya adalah untuk akhirnya menentukan model dalam hal hubungan orangtua-anak. Hindari mengidentifikasi hubungan tidak langsung. Misalnya, jika suatu DEPARTEMEN bertanggung jawab untuk satu atau lebih PROYEK dan setiap PROYEK memulai satu atau lebih TUGAS-PROYEK, maka hubungan antara DEPARTEMEN dan TUGAS-PROYEK tidak diperlukan karena semua TUGAS-PROYEK terkait dengan PROYEK dan semua PROYEK terkait terkait dengan DEPARTEMEN.
Pemodel yang lebih berpengalaman mungkin lebih suka membuat sketsa diagram tingkat entitas daripada benar-benar membangun matriks hubungan. Namun, penting untuk mendefinisikan hubungan ketika mereka diidentifikasi.
Definisi Hubungan-hubungan (Define Relationships)
Langkah selanjutnya adalah mendefinisikan hubungan-hubungan yang telah diidentifikasi.
Definisi-definisi ini meliputi:
1.      Indikasi ketergantungan
2.      Nama hubungan
3.      Pernyataan naratif tentang hubungan
Sebagai hasil dari mendefinisikan hubungan, beberapa hubungan dapat dibatalkan dan hubungan baru ditambahkan. Untuk membangun ketergantungan, hubungan antara dua entitas harus diperiksa di kedua arah. Ini dilakukan dengan menentukan kardinalitas pada setiap akhir hubungan.
Untuk menentukan kardinalitas, asumsikan keberadaan instance dari salah satu entitas. Kemudian tentukan berapa banyak contoh spesifik dari entitas kedua yang bisa dikaitkan dengan yang pertama. Ulangi analisis ini dengan membalik entitas.
Misalnya, pertimbangkan hubungan antara entitas KELAS dan SISWA. SISWA individu dapat didaftarkan dalam nol, satu, atau lebih KELAS. Menganalisis dari arah lain, KELAS individu mungkin memiliki nol, satu, atau lebih SISWA. Oleh karena itu, ada banyak hubungan antara KELAS dan SISWA dengan kardinalitas nol, satu, atau lebih di setiap akhir hubungan. (Catatan: hubungan ini tidak spesifik karena kardinalitas "nol atau satu" atau "tepat satu" tidak ada di kedua ujung hubungan. Hubungan non-spesifik harus diselesaikan kemudian dalam proses pemodelan.)
Ambil hubungan antara entitas PEMBELI dan ORDER-PEMBELIAN sebagai contoh lain. PEMBELI individual dapat mengeluarkan nol, satu, atau banyak ORDER-PEMBELIAN . ORDER-PEMBELIAN individual selalu dikeluarkan oleh PEMBELI tunggal. Oleh karena itu, ada hubungan satu ke banyak antara PEMBELI dan ORDER-PEMBELIAN dengan kardinalitas satu di akhir PEMBELI hubungan dan kardinalitas nol, satu, atau lebih pada akhir ORDER-PEMBELIAN hubungan. (Catatan: ini adalah hubungan khusus karena kardinalitas "tepat satu" ada di akhir hubungan PEMBELI, yaitu. PEMBELI adalah entitas induk dari ORDER-PEMBELIAN).
Setelah dependensi hubungan telah ditetapkan, pemodel kemudian harus memilih nama dan dapat mengembangkan definisi untuk hubungan tersebut. Nama hubungan adalah frasa pendek, biasanya frasa kata kerja dengan hubungannya dengan entitas kedua yang disebutkan. Frasa ini mencerminkan makna hubungan yang diwakili. Seringkali, nama hubungan hanyalah sebuah kata kerja tunggal; Namun, frasa kata kerja juga dapat sering muncul dalam nama hubungan. Setelah nama hubungan dipilih, pemodel harus dapat membaca hubungan dan menghasilkan kalimat yang bermakna mendefinisikan atau menggambarkan hubungan antara dua entitas.
Dalam hal bentuk hubungan spesifik, selalu ada entitas induk dan entitas anak; nama hubungan ditafsirkan dari ujung orang tua terlebih dahulu, kemudian dari anak ke orang tua. Jika ada hubungan kategorisasi antara entitas, ini menyiratkan kedua entitas merujuk ke objek dunia nyata yang sama dan kardinalitas di ujung anak (atau entitas kategori) selalu nol, atau satu. Nama hubungan dihilangkan karena nama “mungkin a” tersirat. Misalnya, KARYAWAN dapat berupa SALARIEDEMPLOYEE.
Dalam kasus berbentuk hubungan non-spesifik, mungkin ada dua nama hubungan, satu untuk setiap entitas, dipisahkan oleh tanda “/”. Dalam hal ini, nama hubungan ditafsirkan dari atas ke bawah atau dari kiri ke kanan, tergantung pada posisi relatif entitas pada diagram, dan kemudian secara terbalik.
Nama hubungan harus membawa makna. Pasti ada substansi dalam apa yang mereka ungkapkan. Makna lengkap, pada kenyataannya, alasan pemodel dalam memilih nama hubungan tertentu, dapat didokumentasikan secara tekstual dengan definisi hubungan. Definisi hubungan adalah pernyataan tekstual yang menjelaskan makna hubungan. Aturan definisi yang sama yang berlaku untuk definisi entitas juga berlaku untuk definisi hubungan:
1.      Mereka harus spesifik
2.      Mereka harus singkat
3.      Mereka harus bermakna
Misalnya, jika hubungan satu ke nol atau satu hubungan didefinisikan antara dua entitas seperti OPERATOR dan WORKSTATION, maka nama hubungan tersebut mungkin bertuliskan "saat ini ditugaskan". Hubungan ini dapat didukung oleh definisi berikut: Setiap operator dapat ditugaskan ke sejumlah workstation selama shift apa pun, tetapi hubungan ini mencerminkan workstation yang ditugaskan operator saat ini.
Membangun Entity-Level Diagrams
Ketika hubungan didefinisikan, pemodel dapat mulai membuat diagram tingkat entitas untuk menggambarkan hubungan secara grafis. Contoh diagram tingkat entitas ditunjukkan pada Gambar 17. Pada tahap pemodelan ini, semua entitas ditampilkan sebagai kotak persegi dan hubungan non-spesifik diizinkan. Jumlah dan ruang lingkup diagram tingkat entitas dapat bervariasi tergantung pada ukuran model dan fokus pengulas individu. Jika memungkinkan, diagram tunggal yang menggambarkan semua entitas dan hubungannya sangat membantu untuk membangun konteks dan memastikan konsistensi. Jika beberapa diagram dihasilkan, pemodel harus berhati-hati agar diagram konsisten satu sama lain serta dengan definisi entitas dan hubungan. Kombinasi diagram tingkat entitas harus menggambarkan semua hubungan yang ditentukan.

Gambar 17. Entity Level Diagram
Sebuah kasus khusus dari diagram tingkat entitas berfokus pada satu entitas dan disebut sebagai "Diagram Entitas." Contoh ditunjukkan pada Gambar 18. Pembuatan diagram entitas untuk setiap entitas adalah opsional, tetapi pedoman khusus harus diikuti jika digunakan:
1.      Entitas subjek akan selalu muncul di perkiraan tengah halaman.
2.      Entitas induk atau generik harus ditempatkan di atas entitas subjek.
3.      Entitas anak atau kategori harus ditempatkan di bawah entitas subjek.
4.      Bentuk hubungan tidak spesifik sering ditampilkan di sisi kotak entitas subjek.
5.      Garis hubungan terpancar dari kotak entitas subjek ke entitas terkait. Satu-satunya asosiasi yang ditunjukkan pada diagram adalah asosiasi antara entitas subjek dan entitas terkait.
6.      Setiap baris hubungan memiliki label yang terdiri dari satu atau dua nama hubungan, dipisahkan oleh garis miring (“/”).

Gambar 18. Phase Two (Entity Level) Diagram Example
Pada titik ini, informasi yang tersedia untuk setiap entitas meliputi yang berikut:
1.      Definisi entitas
2.      Nama hubungan dan definisi opsional (untuk hubungan orang tua dan anak)
3.      Penggambaran dalam satu atau lebih diagram tingkat entitas
Informasi tentang suatu entitas dapat diperluas dengan penambahan diagram referensi, sesuai kebijaksanaan pemodel. Diagram referensi (diagram hanya untuk eksposisi, kadang-kadang disebut FEO) adalah fitur opsional yang tersedia untuk pemodel, yang dapat diterapkan konvensi pemodel individual. Diagram ini adalah platform untuk diskusi antara pemodel dan peninjau. Mereka menawarkan kemampuan unik bagi pemodel untuk mendokumentasikan alasan, mendiskusikan masalah, menganalisis alternatif, dan melihat ke dalam berbagai aspek pengembangan model. Salah satu contoh diagram referensi ditunjukkan pada Gambar 18. Angka ini menggambarkan alternatif yang tersedia dalam pemilihan hubungan dan ditandai dengan preferensi pemodel.
Jenis diagram referensi lain, diilustrasikan oleh Gambar 19, menggambarkan masalah yang dihadapi oleh pemodel. Dalam contoh ini, pemodel telah mengidentifikasi masalah dan kerumitannya untuk perhatian pengulas.

Gambar 19. Reference Diagram (FEO)
Fase Ketiga- Definisi Kunci
Tujuan Tahap Tiga adalah untuk:
1.      Perbaiki hubungan non-spesifik dari Fase Dua.
2.      Tetapkan atribut kunci untuk setiap entitas.
3.      Bermigrasi kunci utama untuk membuat kunci asing.
4.      Validasi hubungan dan kunci

Gambar 20. Example Reference Diagram
Hasil Tahap Tiga digambarkan dalam satu atau lebih diagram Tahap Tiga (level berbasis kunci). Selain menambahkan definisi atribut utama, Fase Tiga akan memperluas dan memperbaiki definisi entitas dan hubungan.
Resolve Non-Specific Relationships
Langkah pertama dalam fase ini adalah untuk memastikan bahwa semua hubungan non-spesifik yang diamati dalam Fase Dua telah disempurnakan. Fase Tiga mensyaratkan bahwa hanya bentuk hubungan tertentu yang digunakan; baik hubungan tertentu (hubungan orangtua-anak) atau hubungan kategorisasi. Untuk memenuhi persyaratan ini, pemodel akan menggunakan penggunaan alternatif perbaikan. Diagram alternatif perbaikan biasanya dibagi menjadi dua bagian: bagian kiri berkaitan dengan subjek (hubungan non-spesifik untuk disempurnakan), dan bagian kanan berkaitan dengan alternatif perbaikan. Contoh alternatif perbaikan yang berhubungan dengan resolusi banyak ke banyak ditunjukkan pada Gambar 21.

Gambar 21. Non-Specific Relationship Refinement
Proses memperbaiki hubungan menerjemahkan atau mengubah setiap hubungan non-spesifik menjadi dua hubungan spesifik. Entitas baru berkembang dari proses ini. Hubungan non-spesifik yang ditunjukkan pada Gambar 21 menunjukkan bahwa ROBBER dapat merampok banyak BANK dan BANK dapat dirampok oleh banyak ROBBERS. Namun, kami tidak dapat mengidentifikasi ROBBER yang merampok BANK mana sampai kami memperkenalkan entitas ketiga, BANK-ROBBERY, untuk menyelesaikan hubungan non-spesifik. Setiap instance entitas BANKROBBERY berhubungan dengan tepat satu BANK dan satu ROBBER.
Pada fase sebelumnya, kita telah bekerja dengan apa yang kita sebut sebagai “entitas alami”. Entitas alami adalah entitas yang mungkin akan kita lihat dibuktikan dalam daftar data sumber atau dalam log bahan sumber. Entitas alami akan mencakup nama-nama seperti berikut:
1.      Pesanan Pembelian
2.      Karyawan
3.      Pembeli
Selama Fase Tiga kita mulai melihat penampilan "entitas asosiatif" atau apa yang secara informal disebut "entitas persimpangan". Entitas titik-temu digunakan untuk menyelesaikan hubungan non-spesifik dan umumnya mewakili pasangan hal-hal yang memiliki karakteristik dasar yang sama (pengidentifikasi unik, atribut, dll.) Sebagai entitas alami. Meskipun entitas BANK-ROBBERY dalam contoh sebelumnya dapat dianggap sebagai entitas alami, itu benar-benar mewakili pasangan ROBBERS dengan BANK. Salah satu perbedaan halus antara entitas alami dan persimpangan adalah dalam nama entitas. Biasanya, nama entitas untuk entitas alami adalah frasa kata benda umum tunggal. Di sisi lain, nama entitas dari entitas persimpangan dapat berupa frase nomina majemuk.
Entitas interseksi lebih abstrak di alam, dan biasanya hasil dari penerapan aturan yang mengatur validitas entitas yang pertama kali diterapkan pada Tahap Tiga. Yang pertama dari aturan ini adalah aturan yang membutuhkan penyempurnaan semua hubungan non-spesifik. Proses penyempurnaan ini adalah langkah besar pertama dalam menstabilkan struktur data terintegrasi
Proses penyempurnaan ini melibatkan sejumlah langkah dasar:
1.      Pengembangan satu atau lebih alternatif penyempurnaan untuk setiap hubungan non-spesifik.
2.      Pemilihan oleh pemodel dari alternatif yang disukai, yang akan tercermin dalam model Fase Tiga.
3.      Pembaruan informasi Tahap Satu untuk memasukkan entitas baru yang dihasilkan dari penyempurnaan.
4.      Pembaruan informasi Tahap Dua untuk menentukan hubungan yang terkait dengan entitas baru.
Depict Function Views
Tingkat volume dan kompleksitas model data pada titik ini mungkin cukup besar. Wajar saja selama Tahap Satu untuk mengevaluasi setiap entitas secara independen dari entitas lainnya. Pada saat itu, entitas hanyalah definisi kata. Dalam Fase Dua, mungkin praktis untuk menggambarkan semua hubungan dalam diagram tunggal karena volume total entitas dan hubungan biasanya tidak terlalu besar. Namun, dalam Fase Tiga, volume entitas dan kompleksitas hubungan yang tercermin dalam model biasanya sedemikian sehingga individu tidak lagi dapat membangun citra mental total dari makna model. Untuk alasan ini, model dapat ditinjau dan divalidasi dari berbagai perspektif. Perspektif ini memungkinkan evaluasi model dengan cara yang lebih langsung terkait dengan aspek fungsional perusahaan yang dimodelkan. Perspektif ini diwakili oleh "tampilan fungsi." Setiap tampilan fungsi digambarkan dalam satu diagram. Tujuannya adalah untuk menetapkan konteks terbatas di mana bagian-bagian model dapat dievaluasi sekaligus.
Tampilan fungsi dapat berperan dalam evaluasi dan validasi model data. Pemodel harus berhati-hati dalam menentukan atau memilih topik yang diilustrasikan dalam tampilan fungsi. Dua metode yang telah digunakan adalah sebagai berikut:
1.      Pilih bahan sumber sampel sebagai topik tampilan fungsi, mis., Pesanan pembelian.
2.      Hubungkan tampilan fungsi dengan kategori pekerjaan atau proses tertentu, yang diwakili oleh departemen organisasi atau area fungsional yang diidentifikasi sebagai sumber di Fase Nol.
Sebagai contoh, pada Gambar 22 data dalam tampilan fungsi sampel dapat digunakan untuk merekonstruksi pesanan pembelian atau untuk merekonstruksi laporan tentang beberapa jumlah pesanan pembelian. Ketika membangun tampilan fungsi, penulis harus memiliki topik dalam pikiran sehingga dapat diungkapkan dengan tepat.
dentify Key Attributes
Fase Tiga dari metodologi IDEF1X berkaitan dengan identifikasi dan definisi elemen data tentang instance entitas yang disebut sebagai key kandidat, kunci primer, kunci alternatif, dan kunci asing. Tujuan langkah ini adalah untuk mengidentifikasi nilai atribut yang secara unik mengidentifikasi setiap instance dari suatu entitas.

Gambar 22. Scope of a Function View
Adalah penting pada titik ini bahwa definisi dan arti dari istilah atribut contoh dan atribut ditekankan. Sebuah instance atribut adalah properti atau karakteristik dari instance entitas. Contoh atribut terdiri dari nama dan nilai. Dengan kata lain, instance atribut adalah salah satu elemen informasi yang diketahui tentang instance entitas tertentu. Contoh atribut adalah deskriptor; artinya, mereka cenderung bersifat seperti kata sifat.
Contoh dari beberapa instance atribut dan instance masing-masing entitas ditunjukkan pada Gambar 23. Perhatikan bahwa instance entitas pertama, atau individu, diidentifikasi dengan nomor karyawan "1," bahwa nama yang terkait dengan instance entitas adalah "Smith," dan bahwa pekerjaan instance entitas adalah "operator." Instance instance ini, secara bersama-sama, secara unik menggambarkan instance entitas dan memisahkan instance entitas dari instance entitas serupa lainnya. Setiap instance atribut memiliki tipe dan nilai. Kombinasi unik dari instance atribut menggambarkan instance entitas tertentu.
Atribut merepresentasikan kumpulan instance atribut dengan tipe yang sama yang berlaku untuk semua instance entitas dari entitas yang sama. Nama atribut biasanya frase nomina deskriptif tunggal. Dalam contoh entitas Karyawan, ada beberapa atribut, termasuk yang berikut:
1.      Nomor karyawan
2.      Nama karyawan
3.      Pekerjaan / posisi karyawan
Contoh bagaimana instance atribut direpresentasikan sebagai atribut juga ditunjukkan pada Gambar 23. Contoh atribut milik instance instans. Tetapi atribut itu sendiri milik entitas. Dengan demikian, asosiasi kepemilikan dibentuk antara entitas dan sejumlah atribut.
Atribut hanya memiliki satu pemilik dalam tampilan. Pemilik adalah entitas tempat atribut berasal. Dalam contoh kami, pemilik atribut EMPLOYEE-NUMBER akan menjadi entitas EMPLOYEE. Meskipun atribut hanya memiliki satu pemilik, pemilik dapat membagikan atribut tersebut dengan entitas lain. Cara kerjanya akan dibahas secara rinci di segmen selanjutnya. Contoh atribut mewakili penggunaan instance atribut untuk menggambarkan properti spesifik dari instance entitas tertentu. Selain itu, beberapa contoh atribut mewakili penggunaan instance atribut untuk membantu mengidentifikasi instance entitas tertentu secara unik. Ini secara informal disebut sebagai atribut utama. Fase Tiga berfokus pada identifikasi atribut kunci dalam konteks model kami. Dalam Fase Empat, atribut bukan kunci akan diidentifikasi dan ditentukan. Satu atau lebih atribut kunci membentuk kunci kandidat suatu entitas. Kunci kandidat didefinisikan sebagai satu atau beberapa atribut kunci yang digunakan untuk mengidentifikasi secara unik setiap instance dari suatu entitas. Nomor karyawan adalah contoh dari satu atribut yang digunakan sebagai kunci kandidat suatu entitas. Setiap karyawan diidentifikasi dari semua karyawan lainnya dengan nomor karyawan. Oleh karena itu, atribut EMPLOYEE-NUMBER adalah kunci kandidat, yang dapat kita katakan secara unik mengidentifikasi setiap anggota entitas EMPLOYEE.

Gambar 23. Attribute Examples
Beberapa entitas memiliki lebih dari satu grup atribut yang dapat digunakan untuk membedakan satu instance entitas dari yang lainnya. Sebagai contoh, pertimbangkan entitas EMPLOYEE dengan atribut EMPLOYEE-NUMBER dan SOCIAL-SECURITY-NUMBER, yang keduanya merupakan kunci kandidat. Untuk entitas semacam itu satu kunci kandidat dipilih untuk digunakan dalam migrasi kunci primer dan ditetapkan sebagai kunci utama. Yang lain disebut kunci alternatif. Jika suatu entitas hanya memiliki satu kunci kandidat, itu secara otomatis adalah kunci utama. Jadi, setiap entitas memiliki kunci utama, dan beberapa juga memiliki kunci alternatif. Jenis mana pun dapat digunakan untuk secara unik mengidentifikasi instance entitas, tetapi hanya kunci utama yang digunakan dalam migrasi kunci. Dalam diagram model, garis horizontal ditarik melalui kotak entitas subjek dan kunci utama ditampilkan di dalam kotak, di atas garis itu. Jika ada lebih dari satu atribut dalam kunci utama (mis., Nomor proyek dan nomor tugas keduanya diperlukan untuk mengidentifikasi tugas-tugas proyek), semuanya muncul di atas garis. Jika suatu entitas memiliki kunci alternatif, entitas tersebut diberi nomor kunci alternatif yang unik. Dalam diagram, angka ini muncul dalam tanda kurung mengikuti setiap atribut yang merupakan bagian dari kunci alternatif. Jika atribut milik lebih dari satu kunci alternatif, masing-masing angka muncul dalam tanda kurung. Jika atribut milik kunci alternatif dan kunci primer, itu muncul di atas garis horizontal diikuti oleh nomor kunci alternatifnya. Jika itu bukan milik kunci utama, itu muncul di bawah garis. Contoh dari berbagai bentuk kunci ditunjukkan pada Gambar 24.
Proses mengidentifikasi kunci terdiri dari:
1.      Identifikasi kunci kandidat untuk suatu entitas.
2.      Memilih satu sebagai kunci utama untuk entitas.
3.      Memberi label kunci alternatif untuk entitas.
Karena beberapa kunci kandidat mungkin merupakan hasil dari migrasi utama, identifikasi kunci adalah proses berulang. Mulailah dengan semua entitas yang bukan anak atau kategori dalam hubungan apa pun. Ini biasanya yang kunci kandidatnya paling jelas. Ini juga merupakan titik awal untuk migrasi kunci primer karena tidak mengandung kunci asing apa pun.

Gambar 24. Key Forms
Migrate Primary Keys
Migrate Primary Keys adalah proses mereplikasi kunci utama satu entitas dalam entitas terkait lainnya. Replika itu disebut kunci asing. Nilai kunci asing di setiap instance dari entitas kedua identik dengan nilai kunci utama dalam instance terkait dari entitas pertama. Ini adalah bagaimana atribut yang dimiliki oleh satu entitas datang untuk dibagikan oleh yang lain. Tiga aturan mengatur migrasi kunci primer:
1.      Migrasi selalu terjadi dari induk atau entitas generik ke entitas anak atau kategori dalam suatu hubungan.
2.      Seluruh kunci utama (yaitu, semua atribut yang merupakan anggota kunci utama) harus dimigrasi satu kali untuk setiap hubungan yang dibagikan oleh pasangan entitas.
3.      Atribut nonkey tidak pernah dimigrasi.
Setiap atribut dalam kunci asing cocok dengan atribut di kunci utama induk atau entitas generik. Dalam hubungan kategori, kunci utama entitas kategori harus identik dengan entitas generik (meskipun nama peran dapat diberikan). Dalam hubungan lain, atribut kunci asing dapat menjadi bagian dari kunci utama entitas anak, tetapi tidak harus demikian. Atribut kunci asing tidak dianggap dimiliki oleh entitas tempat mereka bermigrasi, karena mereka adalah cerminan atribut dalam entitas induk. Dengan demikian, setiap atribut dalam suatu entitas dimiliki oleh entitas itu atau milik kunci asing di entitas itu. Dalam diagram model, kunci asing dicatat sama dengan kunci alternatif, mis., “(FK)” muncul di belakang setiap atribut yang dimiliki kunci asing. Jika atribut juga milik kunci utama, itu di atas garis horizontal; jika tidak, ini di bawah. Jika kunci utama entitas anak berisi semua atribut dalam kunci asing, entitas anak dikatakan "tergantung pengenal" pada entitas induk, dan hubungannya disebut "mengidentifikasi hubungan." Jika atribut apa pun dalam kunci asing bukan milik kunci utama anak, maka anak tersebut bukan pengenal yang bergantung pada induknya, dan hubungannya disebut "tidak mengidentifikasi". Dalam diagram Fase Tiga dan Empat, hanya mengidentifikasi hubungan yang ditampilkan sebagai garis padat; hubungan yang tidak mengidentifikasi ditampilkan sebagai garis putus-putus. Entitas yang merupakan anak dalam satu atau beberapa hubungan identifikasi disebut "entitas yang bergantung pada pengidentifikasi." Satu yang merupakan anak dalam hubungan yang tidak mengidentifikasi (atau bukan anak dalam hubungan apa pun) disebut “entitas pengidentifikasi-independen.” Dalam diagram Fase Tiga dan Empat, hanya entitas pengidentifikasi-independen yang ditampilkan sebagai kotak dengan sudut persegi; entitas dependen ditampilkan sebagai kotak dengan sudut bulat. Contoh migrasi kunci primer dari atribut dari entitas induk ke entitas anak ditunjukkan pada Gambar 25

Gambar 25. Primary Key Migration to an Identifier-Dependent Entity
Dalam contoh ini atribut PELANGGAN-NUMBER (kunci utama entitas PELANGGAN) bermigrasi ke (adalah kunci asing di) entitas PERIKSA. Ini kemudian digunakan dalam entitas PERIKSA sebagai anggota kunci utama bersama dengan atribut lain yang disebut CHECK-NUMBER, yang dimiliki oleh LIHAT. Dua atribut (PELANGGAN-NUMBER dan PERIKSA-NUMBER) bersama-sama membentuk kunci utama untuk PERIKSA. Contoh migrasi kunci utama dari entitas pengidentifikasi-independen ke entitas pengidentifikasi independen lainnya ditunjukkan pada Gambar 26. Dalam contoh ini, atribut DEPARTMENT-NO bermigrasi ke EMPLOYEE. Namun, kunci utama EMPLOYEE adalah EMP-ID. Oleh karena itu, DEPT-NO muncul sebagai kunci asing di bawah garis. Garis hubungan terputus karena itu adalah hubungan yang tidak mengidentifikasi.

Gambar 26. Migration to an Identifier-Independent Entity 
Atribut yang sama dapat menghasilkan lebih dari satu kunci asing di entitas anak yang sama. Ini terjadi ketika atribut bermigrasi melalui dua atau lebih hubungan ke entitas anak. (Lihat bagian 3.9.3.) Dalam beberapa kasus, setiap turunan anak harus memiliki nilai yang sama untuk atribut itu di kedua kunci asing. Ketika ini terjadi, atribut hanya muncul sekali dalam entitas dan diidentifikasi sebagai kunci asing. Dalam kasus lain, turunan anak mungkin (atau harus) memiliki nilai yang berbeda di setiap kunci asing. Dalam kasus ini, atribut muncul lebih dari satu kali dalam entitas dan menjadi perlu untuk membedakan satu kejadian dari yang lain. Untuk melakukannya, masing-masing diberi nama peran yang menunjukkan perbedaan dari yang lain. Gambar 27 menunjukkan contohnya.

Gambar 27. Attribute Role Names
Validate Keys and Relationships
Aturan dasar yang mengatur identifikasi dan migrasi kunci utama adalah:
1. Penggunaan sintaksis hubungan non-spesifik dilarang.
2. Migrasi kunci primer dari entitas induk (atau generik) ke entitas anak (atau kategori) adalah wajib.
3. Penggunaan atribut yang mungkin memiliki lebih dari satu nilai pada suatu waktu untuk instance entitas tertentu dilarang. (Aturan Tanpa Ulangi)
4. Penggunaan atribut kunci primer yang bisa menjadi nol (mis., Tidak memiliki nilai) dalam instance entitas dilarang.
5. Entitas dengan kunci primer majemuk tidak dapat dibagi menjadi beberapa entitas dengan kunci primer lebih sederhana (Terkecil - Aturan Kunci).
6. Pernyataan diperlukan untuk jalur hubungan ganda antara dua entitas.
Kami telah membahas dua aturan pertama di bagian sebelumnya, jadi kami akan mengalihkan perhatian kami ke grup aturan terakhir pada saat ini. Gambar 28 menunjukkan diagram yang berhubungan dengan penerapan "Aturan Tanpa-Ulangi." Perhatikan bahwa subjek diagram menunjukkan PURCHASE-ORDER-NUMBER dan PURCHASE-ORDER-ITEMNUMBER sebagai anggota kunci utama PURCHASE-ORDER. Namun, evaluasi cara PURCHASE-ORDER-ITEM-NUMBER digunakan akan menunjukkan bahwa satu PURCHASE-ORDER (instance entitas) dapat berupa banyak PURCHASE-ORDER-ITEM-NUMBER, satu untuk setiap item yang dipesan. Untuk menggambarkan dengan tepat dalam model data ini, entitas baru yang disebut PURCHASE-ORDER-ITEM harus dibuat, dan label hubungan, sintaksis, dan definisi ditambahkan. Kemudian, karakteristik sebenarnya dari hubungan antara pesanan pembelian dan item pesanan pembelian mulai muncul.

Gambar 28. No-Repeat Rule Refinement
Gambar 29 menunjukkan diagram alternatif penyempurnaan yang berhubungan dengan pemeriksaan nullability atribut. Perhatikan bahwa PART-NUMBER telah bermigrasi ke PURCHASE-ORDER-ITEM. Asosiasi ini didirikan karena item pesanan pembelian terhubung dengan beberapa bagian. Namun, diagram seperti yang ditunjukkan menegaskan bahwa setiap item pesanan pembelian dikaitkan dengan tepat satu nomor bagian. Investigasi (atau mungkin komentar resensi) mengungkapkan bahwa tidak semua item pesanan pembelian dikaitkan dengan bagian-bagian. Beberapa mungkin terkait dengan layanan atau komoditas lain yang tidak memiliki nomor bagian. Ini melarang migrasi PART-NUMBER langsung ke entitas PURCHASE-ORDER-ITEM dan mengharuskan pendirian entitas baru yang disebut ORDERED-PART-ITEM dalam contoh kami. Setelah entitas baru dibuat, migrasi kunci primer harus terjadi seperti yang diamanatkan oleh aturan migrasi, dan pemodel sekali lagi akan memvalidasi struktur hubungan entitas dengan penerapan No-Repeat Rule. Setiap kunci primer majemuk harus diperiksa untuk memastikan kepatuhannya terhadap Aturan Terkecil-Kunci. Aturan ini mensyaratkan bahwa tidak ada entitas dengan kunci primer majemuk yang dapat dibagi menjadi dua atau lebih entitas, dengan kunci primer lebih sederhana (lebih sedikit komponen), tanpa kehilangan beberapa informasi.

Gambar 29. Rule Refinement
Dalam Fase Dua, kecenderungan untuk menentukan hubungan yang berlebihan disebutkan. Namun, analisis Fase Dua terutama bersifat menghakimi pada pihak pemodel. Dengan kunci yang ditetapkan, pemodel sekarang dapat lebih teliti dalam analisis. Jalur ganda hubungan ada kapan saja ada entitas anak dengan dua hubungan yang akhirnya mengarah kembali (melalui satu atau lebih hubungan) ke entitas induk "root" yang sama. Ketika jalur ganda ada, "pernyataan jalur" diperlukan untuk menentukan apakah jalur itu sama, tidak sama, atau tidak pasti. Path sama jika, untuk setiap instance entitas anak, kedua jalur hubungan selalu mengarah ke instance entitas induk root yang sama. Path tidak sama jika, untuk setiap instance dari entitas anak, kedua path hubungan selalu mengarah pada instance berbeda dari induk root. Jalur tidak pasti jika mereka sama untuk beberapa instance entitas anak dan tidak setara untuk yang lain. Jika salah satu jalur hanya terdiri dari satu hubungan tunggal dan jalur sama, maka jalur hubungan tunggal itu berlebihan dan harus dihapus. Kasus paling sederhana dari hubungan jalur ganda adalah di mana kedua jalur terdiri dari hubungan tunggal. Contoh struktur ini ditunjukkan pada Gambar 27. Karena setiap instance dari PART-USAGE dapat berhubungan dengan dua instance PART yang berbeda, tidak ada redundansi. Pernyataan jalur dalam kasus ini akan membutuhkan jalur yang tidak sama, karena BAGIAN tidak dapat dirakit menjadi dirinya sendiri. Jika salah satu jalur terdiri dari beberapa hubungan dan yang lainnya terdiri dari satu hubungan, struktur ini disebut sebagai "triad." Contoh triad ditunjukkan pada Gambar A3.18. Dalam hal ini, KARYAWAN berhubungan dengan DIVISI baik secara langsung maupun tidak langsung melalui DEPARTEMEN. Jika pernyataannya adalah bahwa DIVISI yang dimiliki oleh KARYAWAN adalah DIVISI yang sama dengan DEPARTEMEN-nya (yaitu bagian yang sama), maka hubungan antara DIVISI dan KARYAWAN adalah mubazir dan harus dihapus.

Gambar 30. Example Triad
Pernyataan juga dapat diterapkan pada hubungan jalur ganda ketika kedua jalur tersebut berevolusi lebih dari satu hubungan. Gambar 31 menggambarkan contoh di mana ada dua jalur hubungan antara DEPARTMENT dan TASK-ASSIGNMENT. Jika seorang KARYAWAN hanya dapat ditugaskan ke PROYEK yang dikelola oleh DEPARTEMEN nya, maka jalurnya sama. Jika seorang KARYAWAN hanya dapat ditugaskan untuk suatu PROYEK yang tidak dikelola oleh DEPARTEMEN, maka jalur tidak sama. Jika EMPLOYEE dapat ditugaskan ke PROYEK terlepas dari DEPARTEMEN pengelola, maka jalurnya tidak ditentukan. Jalur tak tentu umumnya diasumsikan kecuali pernyataan yang ditentukan. Pernyataan yang tidak dapat dibuat menggunakan nama peran (lihat bagian 3.9.1.1) harus dilampirkan sebagai catatan pada diagram Fase Tiga (lihat bagian 3.13).

Gambar 31. Path Assertions
Ketika anggota kunci utama diidentifikasi, entri dibuat menjadi kumpulan atribut. Matriks entitas / atribut dapat digunakan untuk mengidentifikasi distribusi dan penggunaan atribut di seluruh model. Matriks memiliki karakteristik sebagai berikut:
1.      Semua nama entitas digambarkan di samping.
2.      Semua nama atribut digambarkan di bagian atas.
3.      Penggunaan atribut oleh entitas digambarkan dalam vektor yang berdampingan, sebagaimana mestinya, menggunakan kode seperti berikut:
1.      “O” = Owner/Pemilik
2.      “K” = Primary key
3.      “M” = Migrated
Contoh matriks entitas / atribut ditunjukkan pada Gambar A3.20. Matriks ini adalah alat utama dalam menjaga kontinuitas model.

Gambar 32. Entity/Attribute Matrix
A3.4.6 Menentukan Atribut Kunci Setelah kunci telah diidentifikasi untuk model, sekarang saatnya untuk mendefinisikan atribut yang telah digunakan sebagai kunci. Dalam Fase Tiga, definisi dikembangkan hanya untuk atribut utama. Pedoman dasar yang sama untuk definisi ini berlaku: mereka harus tepat, spesifik, lengkap, dan dapat dipahami secara universal. Definisi atribut selalu dikaitkan dengan entitas yang memiliki atribut. Artinya, mereka selalu anggota dari kumpulan dokumentasi entitas pemilik. Oleh karena itu, ini hanyalah masalah mengidentifikasi atribut-atribut yang dimiliki oleh setiap entitas, dan digunakan dalam kunci primer atau kunci alternatif entitas tersebut. Dalam contoh yang ditunjukkan pada Gambar 32, atribut-atribut tersebut diberi kode "OK" pada matriks entitas / atribut. Definisi atribut terdiri dari: 1. nama atribut 2. definisi atribut 3. atribut alias A3.4.7 Menggambarkan Hasil Tahap Tiga Sebagai hasil dari identifikasi dan migrasi kunci utama, diagram Function View sekarang dapat diperbarui untuk mencerminkan dan memperbaiki hubungan. Diagram Tampilan Fungsi Tiga Fase juga harus menggambarkan:
1. Atribut utama, alternatif, dan kunci asing.
2. Identifier-independent (sudut persegi) dan entitas yang bergantung pada identifier (rounded corner).
3. Mengidentifikasi hubungan (garis solid) dan non-mengidentifikasi (garis putus-putus). Contoh Tampilan Fungsi Fase tiga ditunjukkan pada Gambar 33. Banyak informasi yang dihasilkan oleh analisis Fase Tiga dapat dilaporkan oleh entitas. Setiap set dokumentasi entitas terdiri dari:
1. Definisi entitas
2. Daftar atribut utama, alternatif, dan kunci asing
3. Definisi untuk atribut primary key yang dimiliki
4. Daftar hubungan di mana entitas adalah entitas generik
5. Daftar hubungan di mana entitas adalah entitas kategori
6. Daftar mengidentifikasi hubungan di mana entitas adalah orang tua
7. Daftar mengidentifikasi hubungan di mana entitas adalah anak
8. Daftar hubungan yang tidak mengidentifikasi di mana entitas tersebut adalah orang tua
9. Daftar hubungan yang tidak mengidentifikasi di mana entitas adalah anak
10. Definisi pernyataan jalur ganda (jika sesuai)
Secara opsional, pemodel mungkin juga ingin membuat diagram individual untuk entitas, mengikuti pendekatan yang sama dengan Diagram Entitas opsional dalam Fase Dua.

Gambar 33. Example of Phase Three Function View Diagram
Bersamaan dengan daftar definisi hubungan yang tabular, referensi silang kembali ke entitas terkait sangat membantu. Atribut yang dimiliki dan dibagikan juga harus dirujuk silang dalam laporan Fase Tiga. Fase Empat - Definisi Atribut Fase Empat adalah tahap akhir pengembangan model. Tujuan dari rencana ini adalah untuk:
1. Mengembangkan kumpulan atribut
2. Menetapkan kepemilikan atribut
3. Tentukan atribut nonkey
4. Validasi dan perbaiki struktur data
Hasil dari Fase Empat digambarkan dalam satu atau lebih Fase Empat (level atribut) diagram. Pada akhir Fase Empat, model data sepenuhnya disempurnakan. Model ini didukung oleh serangkaian definisi dan rujukan silang yang lengkap untuk semua entitas, atribut (kunci dan bukan kunci), dan hubungan.
Identify Nonkey Attributes
Pembangunan pool atribut dimulai pada Fase Tiga dengan identifikasi kunci. Langkah pertama dalam Fase Empat adalah memperluas kumpulan atribut untuk memasukkan atribut nonkey. Kumpulan atribut adalah kumpulan nama atribut yang berpotensi layak. Setiap nama dalam kumpulan atribut hanya muncul satu kali.
Proses membangun atribut pool serupa dengan konstruksi entitas pool. Untuk kumpulan entitas di Fase Satu, kami mengekstraksi nama yang tampaknya merupakan frasa objek kata benda dari daftar data sumber Fasa Zero. Sekarang kita akan kembali ke daftar data sumber dan mengekstrak nama-nama yang tampak sebagai frase nomina deskriptif. Frasa kata benda deskriptif (frasa kata benda yang digunakan untuk menggambarkan objek) biasanya mewakili atribut. Gambar 15 menunjukkan contoh kumpulan atribut.
Banyak nama pada daftar data sumber dari Fasa Nol dimasukkan ke dalam kumpulan entitas di Fase Satu sebagai entitas potensial. Namun, beberapa nama itu mungkin telah diakui oleh Fase Tiga sebagai tidak memenuhi syarat sebagai entitas. Dalam semua kemungkinan, ini adalah atribut. Selain itu, banyak dari nama-nama yang tidak dipilih dari daftar di tempat pertama mungkin atribut. Daftar, kemudian, dalam hubungannya dengan pengetahuan yang diperoleh selama Fase Satu dan Fase Dua, adalah dasar untuk pembentukan kumpulan atribut. Kumpulan atribut adalah daftar atribut yang berpotensi layak diamati dalam konteks model. Daftar ini, kemungkinan besar, akan jauh lebih besar daripada kumpulan entitas. Kumpulan atribut adalah sumber nama atribut yang digunakan dalam model. Dalam hal atribut ditemukan dalam fase selanjutnya dari upaya pemodelan, atribut ditambahkan ke kumpulan atribut dan diberi nomor pengenal unik; mereka kemudian berkembang menjadi penggunaan yang dimaksudkan dalam model.
Establish Attribute Ownership
Langkah selanjutnya mengharuskan setiap atribut bukan kunci ditugaskan ke satu entitas pemilik. Entitas pemilik bagi banyak dari mereka akan terlihat jelas. Misalnya, pemodel harus dapat dengan mudah mengaitkan atribut VENDOR-NAME dengan entitas VENDOR. Namun, beberapa atribut dapat menyebabkan pemodel kesulitan dalam menemukan entitas pemiliknya. Jika pemodel tidak yakin dengan entitas pemilik atribut, ia dapat merujuk ke bahan sumber dari mana atribut diekstraksi. Ini akan membantu dalam penentuan pemilik. Dalam Fase Nol, daftar data sumber dibuat dan menjadi dasar untuk kumpulan atribut. Daftar data sumber mengarahkan pemodel ke lokasi tempat nilai atribut yang diwakili digunakan dalam materi sumber asli. Dengan menganalisis penggunaan atribut dalam materi sumber, pemodel akan dapat lebih mudah menentukan entitas pemilik dalam model data. Pemodel harus mengingat bahwa faktor yang mengatur untuk menentukan kepemilikan atribut adalah kejadian atribut yang diwakili oleh nilai atribut yang tercermin dalam materi sumber. Karena setiap atribut ditugaskan ke entitas pemiliknya, penugasan harus dicatat.

Gambar 34.Sample Attribute Pool
Define Attributes
Menentukan Atribut
Definisi harus dikembangkan untuk masing-masing atribut yang diidentifikasi dalam Fase Empat. Prinsip-prinsip yang mengatur definisi lain yang digunakan dalam model data, dan khususnya yang ada di Fase Tiga, berlaku di sini juga. Definisi yang dikembangkan harus tepat, spesifik, lengkap, dan dapat dipahami secara universal. Definisi atribut ini diproduksi dalam format yang sama dengan definisi atribut dari Fase Tiga. Definisi atribut meliputi:
1. nama atribut
2. definisi atribut
3. atribut alias / sinonim
Setiap atribut harus diberi nama yang unik karena dalam model IDEF1X "aturan nama-sama yang sama artinya" berlaku untuk entitas dan atribut. Oleh karena itu, pemodel mungkin ingin mengadopsi pendekatan standar untuk nama atribut. Namun, nama-nama bahasa Inggris alami yang dikenali pengguna dianjurkan agar mudah dibaca untuk mendukung validasi. Nama atribut yang harus memenuhi aturan bahasa pemrograman yang ketat, mis. tujuh karakter nama variabel FORTRAN harus selalu diidentifikasi sebagai alias jika dimasukkan sama sekali. Dalam definisi atribut, pemodel mungkin ingin mengidentifikasi format atribut, mis. kode alfa-numerik, teks, uang, tanggal, dll. Domain nilai yang dapat diterima juga dapat ditentukan dalam definisi dalam hal daftar, mis. Senin, Selasa, Rabu, Kamis, atau Jumat, atau rentang, mis. lebih besar dari nol tetapi kurang dari 10. Pernyataan yang melibatkan banyak atribut juga dapat ditentukan dalam definisi. Misalnya, atribut EMPLOYEE-SALARY harus lebih besar dari $ 20.000 ketika EMPLOYEE-JOBCODE sama dengan dua puluh.
Memperbaiki Model
Modeler sekarang siap untuk memulai penyempurnaan hubungan Fase Empat. Aturan dasar yang sama yang diterapkan dalam Fase Tiga juga berlaku untuk penyempurnaan ini. Peraturan Tanpa-Ulangi yang diperkenalkan di Fase Tiga sekarang diterapkan untuk atribut kunci dan nonkey. Akibatnya, pemodel dapat berharap menemukan beberapa entitas baru. Ketika entitas-entitas ini diidentifikasi, aturan migrasi kunci utama harus diterapkan, sama seperti pada Tahap Tiga. Satu-satunya perbedaan dalam menerapkan No-Repeat Rule di Fase Empat adalah aturan diterapkan terutama pada atribut nonkey. Gambar 35 mengilustrasikan penerapan No-Repeat Rule ke atribut nonkey.

Gambar 35. Phase Four - Applying the No Repeat Rule
Alternatif untuk segera membuat entitas baru untuk atribut yang melanggar aturan perbaikan adalah dengan menandai pelanggar ketika mereka ditemukan dan membuat entitas baru nanti. Pelanggar Aturan dapat ditandai dengan menempatkan "R" (untuk Aturan Tanpa-Ulangi) dalam tanda kurung mengikuti nama mereka dalam diagram atribut.
Ketika entitas baru muncul, mereka harus dimasukkan dalam kumpulan entitas, didefinisikan, tercermin dalam matriks hubungan, dll. Singkatnya, mereka harus memenuhi semua persyaratan dokumentasi dari fase sebelumnya untuk memenuhi syarat untuk dimasukkan dalam materi Tahap Empat.
Kepemilikan masing-masing atribut juga harus dievaluasi untuk kepatuhan terhadap Aturan Fungsionalitas-Penuh. Aturan ini menyatakan bahwa tidak ada nilai atribut nonkey yang dimiliki dari instance entitas yang dapat diidentifikasi kurang dari seluruh nilai kunci utama untuk instance entitas. Aturan ini hanya berlaku untuk entitas dengan kunci primer majemuk dan setara dengan bentuk normal kedua dalam teori relasional. Sebagai contoh, perhatikan diagram yang ditunjukkan pada Gambar 31. Jika PROJECT-NAME adalah atribut bukan kunci yang dianggap dimiliki oleh entitas TUGAS, itu akan melewati Peraturan Tanpa-Ulangi. Namun, karena NAMA-PROYEK hanya dapat diidentifikasi dari bagian PROJ-NO dari kunci utama TASK, itu tidak memenuhi Aturan Ketergantungan-Fungsional Penuh. PROYEK-NAMA jelas akan menjadi atribut entitas PROYEK.
Semua atribut dalam model Fase Empat juga harus memenuhi aturan No-Transitive-Dependency. Aturan ini mensyaratkan bahwa tidak ada nilai atribut nonkey yang dimiliki dari instance entitas yang dapat diidentifikasi oleh nilai atribut nonkey yang dimiliki atau diwarisi dari instance entitas. Aturan ini setara dengan bentuk normal ketiga dalam teori relasional.
Sebagai contoh, perhatikan entitas EMPLOYEE pada Gambar 31. Jika DEPT-NAME ditambahkan ke entitas EMPLOYEE sebagai atribut bukan kunci, itu akan memenuhi Aturan Tanpa-Ulangi. Namun, karena DEPT-NAME dapat ditentukan dari DEPT-NO yang merupakan atribut bukan kunci yang diwarisi, itu tidak memenuhi Aturan NoTransitive-Dependency dan karenanya, bukan atribut yang dimiliki EMPLOYEE. DEPT-NAME jelas akan menjadi atribut bukan kunci dari DEPARTEMEN entitas.
Cara sederhana untuk mengingat aturan Full-Functional-Dependency dan No-Transitive-Dependency adalah bahwa "atribut nonkey harus bergantung pada kunci, seluruh kunci, dan tidak lain kecuali kunci."
Menggambarkan Hasil Tahap Empat
Sebagai hasil dari populasi atribut, diagram Function View sekarang dapat diperbarui untuk mencerminkan penyempurnaan model dan diperluas untuk menunjukkan atribut nonkey. Atribut bukan kunci tercantum di bawah garis di dalam setiap kotak entitas. Ukuran kotak entitas mungkin perlu diperluas untuk memberikan ruang. Contoh Tampilan Fungsi Fase ditunjukkan pada Gambar 36.
Definisi dan informasi pendukung untuk model harus diperbarui untuk mencerminkan definisi atribut nonkey dan penugasan kepemilikan. Informasi tambahan ini dapat dilaporkan oleh entitas di sepanjang informasi yang didefinisikan sebelumnya. Setiap set dokumentasi entitas sekarang akan terdiri dari:
1. Definisi setiap entitas
2. Daftar atribut utama, alternatif, dan kunci asing
3. Daftar atribut nonkey yang dimiliki
4. Definisi setiap atribut yang dimiliki (baik kunci maupun bukan kunci)
5. Daftar hubungan di mana entitas adalah induknya:
    1. entitas generik dari kategorisasi
    2. mengidentifikasi hubungan orang tua
    3. hubungan orangtua yang tidak teridentifikasi
6. Daftar hubungan di mana entitas adalah anak:
    1. entitas kategori kategorisasi
    2. mengidentifikasi hubungan anak
    3. hubungan anak yang tidak teridentifikasi
7. Definisi asersi jalur ganda
Diagram entitas individu opsional juga dapat diperluas untuk menunjukkan atribut bukan kunci. Definisi hubungan dapat diulang dalam dokumentasi yang ditetapkan untuk setiap entitas atau dicantumkan secara terpisah dengan referensi silang ke entitas tersebut. Atribut kunci dan bukan kunci juga harus terdaftar dan direferensikan silang ke entitas.

Gambar 36. Example of Phase Four Function View Diagram
Bab 3
Visio Viewer
Microsoft Visio adalah aplikasi yang digunakan untuk merancang suatu model perencanaan, model ini dimanfaatkan untuk kebutuhan developer maupun engineering yang didesain untuk berbagai macam kebutuhan.Merupakan suatu aplikasi yang didesain khusus untuk membantu dalam membuat diagram seperti Flowchart, Grantt Chart, Data Flow, Gambar Jaringan, Gambar Denah Bangunan, dan juga pembuatan Gambar Teknik, Gambar Elektronik, serta desain lainnya.yang dirilis oleh Microsoft Corporation. Aplikasi ini menggunakan grafik vektor untuk membuat diagram-diagramnya.
Visio pada awalnya bukanlah buatan Microsoft Corporation, melainkan buatan Visio Corporation, yang diakusisisi oleh Microsoft pada tahun 2000. Versi yang telah menggunakan nama Microsoft Visio adalah Visio 2002, Visio 2003, Visio 2007, Visio 2010, Visio 2013, dan Visio 2016 yang merupakan versi terbaru juga terdapat pula versi webnya.
Fitur-fitur yang ada dalam microsoft visio adalah :
·         AutoConnect - Berfungsi untuk secara otomatis menghubungkan shape baru dengan shape yang telah ada dalamhalaman gambar sekaligus mengatur aligmentnya.
·         Data Link - Untuk mempermudah dalam menghubungkan diagram visio dengan sumber data, menghubungkan sumber data dengan shape data dan mengatur hubungan data yang dibuat.
·         Themes - Digunakan untuk memodifikasi tampilan diagram agar menjadi lebih menarik.
·         Data Graphics - Data yang dapat menvisualisasikan data yang terdapat di dalam shape tertentu
·         Print function integrated. Fungsi print preview dan print telah terintegrasi dengan full-window pada menu File pada offce 2010 yang sangat memudahkan kita
·         Fungsi jump-lists. Dengan fungsi jump-lists kita dapat langsung menuju dokumen yang sebelumnya pernah kita buka atau jalankan melalui StartMenu.
Penjelasan dan Cara Pengeropasian:
Visio memungkinkan mengubah teks dan tabel rumit yang sulit dipahami menjadi diagram visual yang sekilas mengomunikasikan informasi. Ada banyak jenis diagram Visio, termasuk bagan organisasi, diagram jaringan, alur kerja, dan rencana rumah atau kantor. Memulai dengan Visio dapat diringkas menjadi tiga langkah dasar: penggunaan templat, mengatur dan menghubungkan bentuk, dan memodifikasi bentuk dengan teks.
Tutorial: 3 langkah dasar untuk membuat diagram Visio:
1.      Pilih dan buka templat
2.      Atur dan hubungkan bentuk
3.      Tambahkan teks ke bentuk dan konektor
Pilih dan buka templat
Template termasuk stensil, bentuk, dan pengukuran kisi untuk membantu Anda memulai dengan cepat dan mudah saat membuat diagram.
1.      Mulai aplikasi Visio atau buka Visio di web. Jika Visio sudah terbuka, pilih File > New.
Pilih templat yang Anda inginkan, atau pilih Basic Diagram untuk memulai dari awal.
2.      Anda juga dapat menelusuri lebih banyak templat dengan mengklik Categories, dan Anda dapat memasukkan istilah untuk mencari templat. 

Atur dan hubungkan bentuk
Untuk membuat diagram Anda, Anda seret bentuk dari stensil di jendela Bentuk ke kanvas dan hubungkan. Ada beberapa cara untuk menghubungkan bentuk, tetapi cara paling sederhana adalah dengan panah AutoConnect.
1.      Di jendela Shapes, pilih bentuk dan seret ke kanvas. 

2.      Arahkan mouse Anda di atas salah satu panah dan bilah alat kecil muncul dengan empat bentuk teratas di area Quick Shapes. Pilih bentuk yang Anda inginkan dan secara otomatis akan terhubung ke panah yang Anda pilih. 

3.      Anda juga dapat menyeret semua bentuk Anda ke kanvas. Kemudian arahkan mouse di atas bentuk sampai panah muncul. Kemudian ambil panah dan seret ke bentuk yang ingin Anda hubungkan. 

Tambahkan teks ke bentuk dan konektor Sekarang saatnya menambahkan rincian ke diagram Anda dengan menambahkan teks.
1.      Pilih bentuk.
2.      Ketik teks Anda.


Saat Anda mulai mengetik, Visio mengalihkan bentuk yang dipilih ke mode edit teks.
3.      Klik area kosong pada halaman, atau tekan Esc saat Anda selesai. Tambahkan teks ke konektor dengan cara yang sama. Setelah Anda menekan ESC atau mengklik, pilih konektor lagi dan Anda akan melihat kotak kecil pada teks - ini adalah pegangan untuk memindahkan blok teks. Klik dan seret ke atas, bawah, atau di sebelah konektor.
Bab 4
Kasus
Sebuah Bank luar negeri ingin membuat rancangan database menggunakan notasi IDEF1X pada bank dalam Bahasa Inggris. Dengan kriteria tiap relasi antara lain:
1.      Nama bank dengan akun bank
2.      Nasabah dengan akun bank
3.      Akun bank dengan tipe akun
4.      Akun bank dengan transaksi
Langkah--langkah membuat diagram dengan notasi IDEF1X menggunakan Microsoft Visio.
1.      Di Visio, pada menu File, klik New> Software, lalu klik IDEF1X Database Notation.
2.      Pilih antara Unit Metrik atau Unit AS, dan klik Create.
3.      Dari stensil IDEF1X Database Notation, seret bentuk Entity ke halaman gambar untuk membuat entitas induk.
4.      Seret bentuk Entitas lain ke halaman gambar untuk membuat entitas anak.
5.      Di entitas induk, klik atribut yang dilambangkan dengan PK, dan ketik nama atribut. 

6.      Lengkapi entitas induk.
7.      Klik kanan atribut pertama dalam entitas anak, dan pilih Insert ‘Attribute’ Before. 


8.      Klik atribut yang baru dibuat di entitas anak, dan ketik nama atribut yang Anda masukkan sebelumnya sebagai primary key di entitas induk. 

9.      Klik kanan atributnya, dan klik Set Foreign Key.
10.  Seret bentuk Hubungan ke halaman gambar.
11.  Seret salah satu ujung bentuk hubungan ke tengah entitas induk hingga kotak hijau muncul di sekitar seluruh bentuk.
12.  Hubungkan ujung lain dari bentuk hubungan ke entitas anak dengan cara yang sama.
13.  Ulangi langkah-langkah untuk setiap tabel anak hingga selesai. 

Bab 5
KESIMPULAN
Tujuan utama IDEF1X adalah untuk mendukung integrasi. Pendekatan I2S2 untuk integrasi berfokus pada penangkapan, pengelolaan, dan penggunaan definisi semantik tunggal dari sumber data yang disebut sebagai "Skema Konseptual." "Skema konseptual" memberikan definisi tunggal terintegrasi data dalam suatu perusahaan yang tidak memihak terhadap aplikasi tunggal data dan tidak tergantung pada bagaimana data disimpan atau diakses secara fisik. Tujuan utama skema konseptual ini adalah untuk memberikan definisi yang konsisten tentang makna dan keterkaitan data yang dapat digunakan untuk mengintegrasikan, berbagi, dan mengelola integritas data.
Penutup
Tidak dipungkiri bahwa dalam penulisan buku ini masih banyak kesalahan dan masih jauh dari kata sempurna. Akan tetapi dalam proses pengerjaannya kami sudah berusaha semampu kami. Harapanya buku ini dapat memberi manfaat tidak hanya bagi para pembaca tapi juga bagi kami sendiri. Sekian, akhir kata dari kami kritik dan saran yang membangun kiranya dapat kami terima demi kesempurnaan penulisan.
Daftar Pustaka
Brown,
R. G., Logical Database Design Techniques, The Database Design Group, Inc., Mountain View, California, 1982.
Brown,
R. G., IDEF1X Formalization, The Database Design Group, Inc., 1993.
Brown,
R. G. and Parker, D. S. "LAURA, A Data Model and Her Logical Design Methodology," Proc. 9th VLDB Conf., Florence, Italy, 1983.
Bruce,
T. A., Designing Quality Databases with IDEF1X Information Models, Dorset House, 1992.
Chen,
P. P., The Entity-Relationship Model -- Toward a Unified View of Data, ACM Trans. on Database Systems, Vol. 1, No. 1, March 1976, hal. 9-36.
Codd,
E. F., "A Relational Model of Data for Large Shared Data Banks," Communications ACM, Vol. 13, No. 6, June 1970, hal. 377-387.
Codd,
E. F., "Extending the Database Relational Model to Capture More Meaning," ACM Trans. on Database Systems, Vol. 4, No. 4, December 1979, hal. 397-434.
General
Electric Company, "Integrated Information Support System (IISS), Vol V,-Commond Data Model Subsystem, Part IV-Information Modeling Manual-IDEF1 Extended", AFWAL-TR-86-4006, Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, November 1985.
Hammer,
M. and McLeod, D., "The Semantic Data Model: a Modeling Mechanism for Data Base Applications," Proc. ACM SIGMOD Int’l. Conf. on Management of Data, Austin, Texas, May 31 - June 2, 1978, hal. 26-36.
Hogger,
C. J., Introduction to Logic Programming, Acedemic Press, 1984.
"Information
Processing Systems - Concepts and Terminology for the Conceptual Schema and the Information Base," ISO Technical Report 9007, 1987.
Loomis, M.E.S., The Database Book, Macmillan, 1987.
Manna,
Z. and Waldinger, R., The Logical Basis for Computer Programming, Volume 1, AddisonWesley, 1985.
Shipman,
D. W., "The Functional Data Model and the Data Language DAPLEX," ACM Trans. on Database Systems, Vol. 6, No.1, March 1981, hal. 140-173.
Smith,
J. M. and Smith, D. C. P. "Database Abstractions: Aggregation," Communications ACM, Vol. 20, No. 6, June 1977, hal. 405-413.
Smith,
J. M. and Smith, D. C. P. "Database Abstractions: Aggregation and Generalization," ACM Trans. on Database Systems, Vol. 2, No. 2, June 1977, hal. 105-133.
SofTech,
"ICAM Architecture Part II - Volume V - Information Modeling Manual (IDEF1)," AFWAL-TR-81-4023, Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, June 1981.

Continue Reading
0
Posted by at 05:21 No comments:

About Us

Recent

Random