Бібліографічний опис:
Ключові слова: база даних, сутність, атрибут, відділ кадрів, первинний ключ, зовнішній ключ
Як предметної області будемо розглядати діяльність відділу кадрів. Визначаємо суті і їх Атрібутний склад на інтуїтивному рівні, т. Е. Визначаємо, якими типами даних характеризується наш об'єкт досліджень.
Сутність (рис.1) - об'єкт будь-якої природи дані, про який зберігаються в відношенні (таблиці, в якій містяться дані). Кожна сутність в ER-моделі зображується у вигляді прямокутника з найменуванням:
Мал. 1. Сутність - «Склад сім'ї співробітника»
Суті, містять різні атрибути. Атрибут (рис.2) - властивість сутності (заголовок стовпчика таблиці). Атрибути зображуються у межах прямокутника, що визначає сутність:
Мал. 2. Атрибути - сутності «Склад сім'ї співробітника»
Кожен екземпляр сутності повинен бути унікальний і відрізнятися про інших примірників. Для виділення примірників, пошуку їх в базі даних, зв'язку з іншими таблицями використовуються атрибути, однозначно визначають той чи інший об'єкт. Такі атрибути називають ключами. Розрізняють первинні ключі і зовнішні: первинний ключ (primary key) - це атрибут або група атрибутів, однозначно ідентифікують екземпляр сутності, атрибути первинного ключа на діаграмі не вимагають спеціального позначення - це ті атрибути, які знаходяться в списку атрибутів вище горизонтальної лінії; зовнішні ключі (Foreign Key) створюються автоматично, коли зв'язок з'єднує сутності: зв'язку утворюють посилання на атрибути первинного ключа в дочірній сутності і ці атрибути утворюють зовнішній ключ в дочірньої сутності (міграція ключа). Атрибути зовнішнього ключа позначаються символом (FK) після свого імені [1].
Склад атрибутів і їх опис, первинні і альтернативні ключі для розробки бази даних відділу кадрів представлені в таблицях нижче:
Атрибути сутності «Склад сім'ї співробітника» (FAMILY_COMPOSITION_WORKER)
Назва на логічному рівні
Для створення бази даних «Кадри» були взяті тільки деякі найосновніші суті в кількості, достатній для простеження основних закономірностей, звичайно, цих даних набагато менше, ніж може міститися в реальній базі даних, присвяченій діяльності кадрової служби, ось деякі з тих, що не розгледіли : облік особового складу (особисті справи, особові картки, анкети); видані довідки; трудові книжки (прийом, заповнення, зберігання і видача трудових книжок); графік відпусток; відрядження (оформлення та облік відряджень); табельний облік; підвищення кваліфікації; військовий облік і ін. Наведений приклад бази даних «Кадри», легко доповнюється при необхідності розробки професійної бази даних.
Мал. 3. Логічна модельЛогічний рівень представлення моделі даних - це рівень абстрактного, понятійного відображення інформаційних масивів, при якому підкреслюється предметна сторона розглянутої реальності.Прі високорівневої проектуванні баз даних використовується ER- модель. З її допомогою можна виділити ключові сутності і позначити зв'язки, які можуть встановлюватися між цими сутностями, модель представляється у вигляді діаграми. На рис.3 відображена логічна модель даних описуваної системи. Лінії між ними визначають наявність зв'язків, а значки на кінцях - вид зв'язку (рис.4).
Мал. 4. Види зв'язків
Концепція залежних і незалежних сутностей посилюється типом взаємозв'язків між двома сутностями. Якщо необхідно, щоб зовнішній ключ передавався в дочірню сутність (і, в результаті, створював залежну сутність), то можете створити ідентифікує зв'язок між батьківської та дочірньої сутність. Ідентифікують взаємозв'язку позначаються суцільною лінією між сутностями.
Неідентіфіцірующей зв'язку, які є унікальними, також пов'язують батьківську сутність з дочірньою. Неідентіфіцірующей зв'язку використовуються для відображення іншого типу передачі атрибутів зовнішніх ключів - передача в область даних дочірньої сутності (під лінією). Неідентіфіцірующей зв'язку відображаються пунктирною лінією між об'єктами. Так як передані ключі в неидентифицирующей зв'язку не є складовою частиною первинного ключа дочірньої сутності, то цей вид зв'язку не проявляється ні в одній ідентифікуючої залежності.
Останній етап моделювання бази даних - перехід до фізичного рівня моделі, на якому модель також представлена у вигляді діаграми (рис.5).
Мал. 5. Фізична модель
Основною метою процесу проектування є генерація фізичної схеми бази даних відділу кадрів. Отриманий SQL-скрипт:
CREATE TABLE DETAILS__WORKER (
MAR_STATUS_CODE INTEGER NOT NULL,
OFFICER_CODE INTEGER NOT NULL,
MANNING_TABLE_CODE INTEGER NOT NULL,