Sebagai contoh bagaimana data dapat diatur secara konseptual, kita akan menggambarkan model data relasional. Dalam model konseptual, data dalam database dipandang sebagai diatur dalam serangkaian hubungan atau tabel data yang terkait dalam cara didefinisikan dalam kamus data.
Suatu relasi terdiri dari baris data dengan kolom berisi atribut tertentu. Istilah "relasional" berasal dari teori matematika hubungan yang memberikan kerangka teoritis untuk jenis model data.
Di sini, istilah "hubungan" dan data "tabel" akan digunakan secara bergantian.
Tabel 14-2 mendefinisikan satu hubungan yang mungkin untuk merekam data biaya unit yang terkait dengan kegiatan tertentu. Termasuk dalam database akan menjadi satu baris (atau tuple) untuk masing-masing dari berbagai item yang terlibat dalam konstruksi atau kegiatan-kegiatan proyek lainnya. Biaya unit informasi yang terkait dengan setiap item kemudian disimpan dalam bentuk hubungan didefinisikan dalam Tabel 14-2.
TABEL 14-2 Ilustrasi Uraian Hubungan: Atribut Harga Unit Informasi | |||
Nama Atribut | Atribut Keterangan | Jenis Atribut | Kunci |
ITEM_CODE DESKRIPSI WORK_UNIT CREW_CODE OUTPUT TIME_UNIT MATL_UNIT_COST DATEMCOS INSTCOST DATEICOS | Barang Nomor Kode Item Description Standar Unit Bekerja untuk Item Kru Standar Kode untuk Aktivitas Rata-rata Produktivitas Crew Standar Unit OUTPUT Bahan Satuan Biaya Tanggal MATL_UNIT_COST Instalasi Satuan Biaya Tanggal INSTCOST | Pra-didefinisikan Kode Teks Teks (Terbatas untuk unit yang diijinkan) Pra-didefinisikan Kode Numerik Teks Numerik Tanggal Teks Numerik Tanggal Teks | Ya Tidak ada Tidak ada Tidak ada Tidak ada Tidak ada Tidak ada Tidak ada Tidak ada Tidak ada |
Menggunakan Tabel 14-2, biaya masuk unit yang khas untuk suatu kegiatan dalam konstruksi mungkin: ITEM_CODE: 04.2-66-025 DESKRIPSI: batu bata yang umum, 12 "tembok tebal, 19,0 bata per SF WORK_UNIT: 1000 batu bata CREW_CODE: 04.2-3 OUTPUT: 1,9 TIME_UNIT: Shift MATL_UNIT_COST: 124 DATEMCOS: Juni-09-79 INSTCOST: 257 DATEICOS: Agustus-23-79
Entri ini merangkum unit biaya yang terkait dengan pembangunan 12 "dinding pasangan bata bata tebal, seperti yang ditunjukkan oleh deskripsi item ITEM_CODE adalah sebuah kode numerik mengidentifikasi kegiatan tertentu Kode ini mungkin mengidentifikasi kategori umum juga;.. Dalam hal ini, 04,2 mengacu bekerja batu umum. ITEM_CODE mungkin didasarkan pada MASTERFORMAT atau skema pengkodean lainnya. Catatan CREW_CODE mengidentifikasi awak standar yang akan terlibat dalam kegiatan ini. Komposisi aktual dari kru standar akan ditemukan di HUBUNGAN CREW di bawah entri 04,2 -3, yang merupakan awak standar ketiga yang terlibat dalam pekerjaan pasangan bata (04.2). Kemampuan untuk menunjuk ke hubungan lainnya mengurangi redundansi atau duplikasi informasi dalam database. Dalam hal ini, awak nomor standar 04.2-3 dapat digunakan untuk berbagai tugas konstruksi pasangan bata, tetapi definisi kru ini hanya perlu muncul sekali.
WORK_UNIT, OUTPUT dan TIME_UNIT meringkas output yang diharapkan untuk tugas ini dengan kru standar dan menentukan unit standar pengukuran untuk item. Dalam hal ini, biaya diberikan per seribu batu bata per shift. Akhirnya, bahan (MATL_UNIT_COST) dan instalasi (INSTCOSTS) biaya dicatat bersama dengan tanggal (DATEMCOS dan DATEICOS) di mana harga yang tersedia dan dimasukkan dalam database. Tanggal masuk berguna untuk memastikan bahwa setiap inflasi di biaya dapat dipertimbangkan selama penggunaan data.
Data direkam dalam setiap baris dapat diperoleh dengan survei selama persiapan tawaran, dari pengalaman proyek sebelumnya atau dari layanan komersial. Sebagai contoh, data yang tercatat dalam Tabel 14-2 hubungan bisa diperoleh sebagai rata-rata nasional dari sumber komersial.
Keuntungan dari model database relasional adalah bahwa jumlah atribut dan baris dalam setiap relasi dapat diperluas seperti yang diinginkan. Misalnya, seorang manajer mungkin ingin untuk membagi biaya bahan (MATL_UNIT_COST) menjadi atribut untuk bahan tertentu seperti semen, agregat dan bahan lainnya dari beton dalam hubungan biaya satuan didefinisikan dalam Tabel 14-2. Sebagai barang tambahan ditentukan atau diperlukan, data mereka yang terkait dapat dimasukkan dalam database sebagai baris lain (atau tuple) dalam hubungan biaya unit. Juga, hubungan baru dapat didefinisikan sebagai kebutuhan. Oleh karena itu, model relasional organisasi database dapat cukup fleksibel dalam aplikasi. Dalam prakteknya, ini merupakan keuntungan penting. Sistem aplikasi dapat diharapkan untuk mengubah secara radikal dari waktu ke waktu, dan sistem yang fleksibel sangat diinginkan.
Dengan database relasional, adalah mudah untuk mengeluarkan pertanyaan untuk item data tertentu atau untuk menggabungkan data dari hubungan yang berbeda. Misalnya, seorang manajer mungkin ingin untuk menghasilkan laporan komposisi kru diperlukan pada sebuah situs untuk mencapai daftar yang diberikan tugas. Perakitan laporan ini akan membutuhkan mengakses informasi harga satuan untuk menemukan kru standar dan kemudian menggabungkan informasi tentang kegiatan konstruksi atau item (misalnya kuantitas yang diinginkan) dengan informasi awak. Namun, untuk secara efektif mencapai hal ini jenis manipulasi memerlukan definisi "kunci" dalam setiap relasi.
Dalam Tabel 14-2, ITEMCODE menyediakan pengenal unik atau kunci untuk setiap baris. Tidak ada baris yang lain harus memiliki ITEMCODE yang sama dalam hubungan satu.
Memiliki kunci yang unik mengurangi redundansi data, karena hanya satu baris yang termasuk dalam database untuk setiap kegiatan. Ini juga menghindari kesalahan. Misalnya, salah satu tanya database untuk menemukan biaya bahan dimasukkan pada tanggal tertentu.
Tanggapan ini mungkin menyesatkan karena lebih dari satu biaya bahan bisa saja masuk pada tanggal yang sama. Demikian pula, jika ada beberapa baris dengan nilai ITEMCODE sama, maka query akan memberikan respon yang keliru jika salah satu baris itu keluar dari tanggal. Akhirnya, setiap baris hanya memiliki satu entri untuk setiap atribut.
Kemampuan untuk menggabungkan atau memisahkan hubungan ke dalam pengaturan baru memungkinkan definisi pandangan-pandangan alternatif atau model eksternal informasi.
Karena biasanya ada beberapa pengguna yang berbeda dari database, ini bisa sangat berguna. Misalnya, pembagian gaji dari suatu organisasi biasanya akan menginginkan sebuah organisasi yang sangat berbeda informasi tentang karyawan daripada seorang manajer proyek. Dengan secara eksplisit mendefinisikan jenis dan organisasi informasi kelompok pengguna tertentu atau aplikasi membutuhkan, pandangan tertentu atau subset dari seluruh database dapat dibangun. Organisasi ini diilustrasikan pada Gambar. 14-1 dengan KAMUS DATA melayani sebagai penerjemah antara model data eksternal dan sistem manajemen database.
Di balik operasi yang terkait dengan query dan memanipulasi hubungan adalah teori aljabar eksplisit. Aljabar ini mendefinisikan berbagai operasi yang dapat dilakukan pada hubungan, seperti serikat pekerja (terdiri dari semua baris milik satu atau yang lain dari dua relasi), persimpangan (terdiri dari semua baris milik berdua dua relasi), dikurangi (terdiri dari semua baris milik satu relasi dan bukan orang lain), atau proyeksi (terdiri dari subset dari atribut dari relasi). Dasar-dasar aljabar relasional database izin definisi ketat dan keyakinan bahwa operasi akan dilakukan dalam mode yang diinginkan.
Contoh 14-3: Sebuah Hubungan Subkontraktor
Sebagai ilustrasi dari diskusi sebelumnya,mempertimbangkan masalah mengembangkan database dari subkontraktor mungkin untuk proyek-proyek konstruksi. Database ini mungkin diinginkan oleh departemen estimasi biaya kontraktor umum untuk mengidentifikasi subkontraktor untuk meminta untuk tawaran pada bagian-bagian dari proyek.
Subkontraktor yang tepat muncul dalam database bisa dihubungi untuk mempersiapkan tawaran untuk proyek-proyek tertentu. Tabel 14-3 berisi daftar berbagai atribut yang mungkin diperlukan untuk suatu daftar dan contoh entri, termasuk nama subkontraktor, kontak person, alamat, ukuran (besar, menengah atau kecil), dan kemampuan.
TABEL 14-3 Subkontraktor Hubungan Contoh | |
Atribut | Contoh |
NAMA KONTAK TELEPON STREET KOTA NEGARA ZipCode UKURAN BETON LISTRIK MASONRY dll | XYZ Electrical Co Betty XYZ (412) xxx-xxxx xxx Mulberry St Pittsburgh PA 152xx besar tidak ada ya tidak ada |
Untuk menggunakan hubungan ini, seorang estimator biaya mungkin tertarik dalam mengidentifikasi besar, subkontraktor listrik di database. Sebuah query diketik ke dalam DBM seperti: SELECT dari subkontraktor mana SIZE = Besar dan LISTRIK = Ya akan menghasilkan pemilihan semua subkontraktor yang besar melakukan pekerjaan listrik dalam kaitannya subkontraktor. Lebih khusus, estimator mungkin ingin untuk menemukan subkontraktor dalam keadaan tertentu: SELECT dari subkontraktor mana SIZE = Besar dan LISTRIK = NEGARA = Ya dan VI.
Selain memberikan daftar nama-nama subkontraktor yang diinginkan dan alamat, program aplikasi utilitas juga bisa ditulis yang akan mencetak label surat untuk perusahaan yang dipilih.
Bagian lain dari perusahaan kontraktor umum juga mungkin ingin menggunakan daftar ini. Sebagai contoh, departemen akuntansi mungkin menggunakan hubungan ini untuk mencatat alamat subkontraktor untuk pembayaran faktur, sehingga menghindari keharusan untuk mempertahankan file duplikat. Dalam kasus ini, kode akuntansi angka terkait dengan subkontraktor masing-masing mungkin dimasukkan sebagai atribut tambahan dalam relasi, dan departemen akuntansi bisa menemukan alamat secara langsung.
Contoh 14-4: Hubungan Kerja pada Sejarah Jembatan
Sebagai contoh lain sederhana dari sebuah tabel data, pertimbangkan hubungan ditunjukkan pada Tabel 14-0 yang mungkin merekam pengalaman historis dengan berbagai jenis jembatan dikumpulkan oleh suatu instansi tertentu. Contoh aktual atau baris data dalam Tabel 14-4 adalah hipotetis.
Atribut dari relasi ini adalah:
• NOMOR PROYEK - kode 6-digit mengidentifikasi proyek tertentu.
• JENIS BRIDGE - bidang teks yang menjelaskan tipe jembatan. (Untuk tujuan pengambilan, kode numerik juga dapat digunakan untuk menggambarkan tipe jembatan untuk menghindari perbedaan dalam terminologi untuk menggambarkan jembatan serupa).
• LOKASI - Lokasi proyek.
• CROSSING - Apa jembatan menyilang, misalnya. sungai.
• SITUS KONDISI - Deskripsi singkat tentang keanehan situs.
• EREKSI WAKTU - Waktu yang dibutuhkan untuk mendirikan jembatan, dalam beberapa bulan.
• SPAN - Rentang jembatan di kaki.
• TANGGAL - Tahun penyelesaian jembatan.
• ESTIMASI BIAYA AKTUAL-- Selisih aktual dari biaya perkiraan. Atribut ini dapat digunakan untuk menjawab berbagai pertanyaan mengenai pengalaman konstruksi berguna selama perencanaan awal. Sebagai contoh, anggaplah bahwa jembatan akan dibangun dengan rentang 250 meter, yang terletak di Pittsburgh PA, dan menyeberangi sungai dengan batu kapur sub-strata.
Dalam perencanaan awal atau pendahuluan, desainer mungkin query database empat kali terpisah sebagai berikut:
• SELECT dari Pekerjaan Jembatan SPAN> 200 dan SPAN <300 dan di mana CROSSING = "sungai"
• SELECT dari Pekerjaan Jembatan SPAN> 200 dan SPAN <300 dan di mana KETENTUAN SITUS = "Kapur"
• SELECT dari Pekerjaan Jembatan JENIS BRIDGE = "Baja Plat BALOK UTAMA" dan LOKASI = "PA"
• SELECT dari Pekerjaan Jembatan SPAN <300 dan SPAN> 200 dan BIAYA ESTIMASI KURANG SEBENARNYA <100.000.
• SELECT dari Pekerjaan Jembatan SPAN> 200 dan SPAN <300 dan di mana KETENTUAN SITUS = "Kapur"
• SELECT dari Pekerjaan Jembatan JENIS BRIDGE = "Baja Plat BALOK UTAMA" dan LOKASI = "PA"
• SELECT dari Pekerjaan Jembatan SPAN <300 dan SPAN> 200 dan BIAYA ESTIMASI KURANG SEBENARNYA <100.000.
Setiap operasi SELECT akan menghasilkan contoh jembatan dalam database yang sesuai dengan kriteria seleksi yang diinginkan.
Dalam praktek, program penerjemah input / output harus tersedia untuk menerjemahkan pertanyaan-pertanyaan dari dan ke DBM dan bahasa berorientasi masalah yang tepat.
Keempat query dapat mewakili pikiran berikutnya dari seorang desainer dihadapkan dengan kondisi ini masalah. Dia pertama mungkin bertanya, "Apa pengalaman yang kita miliki dengan jembatan rentang ini atas sungai-sungai?" "Apa pengalaman yang kita miliki dengan jembatan rentang ini dengan kondisi lokasi Apa pengalaman kami dengan jembatan gelagar baja di Pennsylvania? Untuk jembatan rentang ini, berapa banyak dan yang didirikan tanpa biaya yang cukup besar dikuasai?? Kita bisa menimbulkan banyak pertanyaan jenis ini umumnya hanya menggunakan tabel data kecil ditunjukkan pada Tabel 14-4.
