2.3 Короткий опис мови моделювання, що використовується
В наш час у реальному проектуванні структури бази даних широко застосовується семантичне моделювання. Семантичне моделювання являє собою моделюванням структури даних, що спирається на зміст цих даних. Як інструмент семантичного моделювання використовуються різні варіанти діаграм «сутність-звязок» (ERD - Entity-Relationship Diagram). Всі варіанти діаграм «сутність-звязок» використовують графічне зображення сутностей предметної області, їх властивостей (атрибутів), і взаємозвязків між сутностями.
Основні поняття ERD
Сутність - це клас однотипних обєктів, інформація про які повинна бути врахована в моделі. Кожна сутність повинна мати найменування, виражене іменником в однині. Кожна сутність у моделі зображується у вигляді прямокутника з найменуванням.
Екземпляр сутності - це конкретний представник даної сутності. Екземпляри сутностей повинні бути помітні, тобто сутності повинні мати деякі властивості, унікальні для кожного примірника цієї сутності.
Атрибут сутності - це іменована характеристика, що є деякою властивістю сутності.
Найменування атрибута має бути виражене іменником в однині. Атрибути зображуються в межах прямокутника, що визначає сутність.
Ключ сутності - це не надмірний набір атрибутів, значення яких в сукупності є унікальними для кожного екземпляра сутності. Ненадмірність полягає в тому, що видалення будь-якого атрибута з ключа порушує його унікальність.
Сутність може мати кілька різних ключів. Ключові атрибути зображуються на діаграмі символом «#»
Звязок - це деяка асоціація між двома сутностями. Одна сутність може бути повязана з іншою сутністю або сама з собою. Звязки дозволяють по одній сутності знаходити інші сутності, повязані з нею. Кожна звязок має два кінці і одне або два найменування. Найменування зазвичай виражається в невизначеній формі дієслова: "мати", "належати" і т.п. Кожне з найменувань відноситься до свого кінця звязку. Іноді найменування не пишуться через їх очевидності.
Кожен звязок може мати один з типів звязку: один-до-одного () , один-до-багатьох () и багато-до-багатьох ().
|
Один-до-одного |
Один екземпляр першої сутності (лівої) повязаний з одним екземпляром другої сутності (правої). Звязок один-до-одного частіше за все свідчить про те, що насправді ми маємо всього одну сутність, помилково розділену на дві |
|
|
Один-до-багатьох |
Один екземпляр першої сутності (лівої) повязаний з декількома екземплярами другої сутності (правої). Це найбільш часто використовуваний тип звязку. Ліва сутність (з боку "один") називається батьківського, права (з боку "багато") - дочірньою |
|
|
Багато-до-багатьох |
Звязок типу означає, що кожен екземпляр першої сутності може бути повязаний з декількома екземплярами другої, і кожен екземпляр другої сутності може бути повязаний з декількома екземплярами першої. Тип звязку багато-до-багатьох є тимчасовим типом звязку, допустимим на ранніх етапах розробки моделі. Надалі цей тип звязку повинен бути замінений двома звязками типу один-до-багатьох шляхом створення проміжної сутності |
Кожен звязок може мати одну з двох модальностей звязку: «може» () і «повинен» ().
|
Може |
Екземпляр однієї сутності може бути повязаний з одним або кількома екземплярами іншої сутності, а може бути і не повязаний ні з одним екземпляром |
|
|
Повинен |
Екземпляр однієї сутності зобовязаний бути повязаний не менш ніж з одним екземпляром іншої сутності |
Описаний графічний синтаксис дозволяє однозначно читати діаграми, користуючись наступною схемою побудови фраз: <Кожен екземпляр СУТНОСТІ 1> <МОДАЛЬНІСТЬ ЗВЯЗКУ> <НАЙМЕНУВАННЯ ЗВЯЗКУ> <ТИП ЗВЯЗКУ> <екземпляр СУТНОСТІ 2>.
- 1. Вступ
- 2. Методи й засоби проектування баз даних
- 2.1 Опис основних етапів проектування баз даних
- 2.2 Опис методології проектування
- 2.3 Короткий опис мови моделювання, що використовується
- 3. Стратегія автоматизації
- 3.1 Короткий опис предметної області із зазначенням поточних цілей і задач
- 3.2 Цілі та задачі автоматизації
- 3.3 Декларація вимог до проектованої системи баз даних (вимоги до інформаційного, математичного, програмного, технічного, організаційного забезпечення)
- 4. Системний аналіз предметної області
- 4.1 Опис інформаційного забезпечення (сутності, звязки, атрибути, домени, обмеження цілісності)
- 4.2 Опис звязків між даними та задачами (матриця задачі/дані)
- 4.3 Опис необхідності захисту даних та рівня цього захисту
- 4.4 Опис заходів, необхідних для контролю даних у базі даних, їх резервного копіювання та відновлення
- 5. Концептуальне моделювання предметної області
- 5.1 ERD предметної області, що автоматизується
- 5.2 Змістовний опис обмежень цілісності
- 6. Логічний проект бази даних
- 6.1 Опис таблиць бази даних з обмеженнями цілісності
- 6.2 Опис запитів по вибору даних, що реалізують описані задачі
- Висновки
- 2. Державна належність та реєстрація повітряних суден.
- 3. Сертифікація та порядок допуску повітряних суден до експлуатації.
- 2.2.2Характеристика повітряних суден
- 4. Юридичний статус повітряних суден та їх екіпажу при міжнародних польотах
- Стаття 41. Виключення повітряного судна з Державного реєстру цивільних повітряних суден України
- Стаття 39. Реєстрація цивільних повітряних суден
- Стаття 46. Польоти повітряних суден
- Стаття 61. Робочий час членів екіпажу цивільних повітряних суден
- 2) Якими нормативними актами регулюється оренда та реєстрація повітряних суден?