Розробка стратегії, аналіз, концептуальне моделювання та проектування бази даних соціальної мережі

Ключовими результатами етапу  концептуального моделювання э  наступні:

• формальний опис інформаційного забезпечення предметної області.
• докладний і строгий опис сховищ даних.
• детальний опис потоків даних.
• детальний опис ієрархії розв'язуваних завдань із детальною специфікацією всіх завдань.
• детальний опис діючих у предметній області правил і обмежень.

Існує безліч мов, які претендують  на роль мов концептуального моделювання  ПО. У цей час найбільш популярними  й повсюдно використовуваними є  мови, що ставляться до класу, так званих, графічних мов, що оперують з такими поняттями, як сутність-атрибут-зв'язок. У наступному розділі ми коротко  опишемо одну з таких мов яка  отримала назву мови ER-моделювання  предметних областей. Саме ця мова буде використана для представлення  концептуальної моделі ПО проходження  практики студентами.

3.2. Мова ER—моделювання ПО

Мова ER-моделювання (Entity Relationship Modeling) — це мова визначення інформаційних  потреб організації. Мова базується  на концепції, відповідно до якої інформаційне забезпечення будь-якої предметної області  представляється як сукупність взаємозалежних об'єктів. Процес моделювання полягає у виділенні сутностей ПО, установлення властивостей виділених сутностей і виявлення існуючих між ними зв'язків.

Моделювання сутностей і  зв'язків може використовуватися  не тільки на етапі концептуального  моделювання, але і на етапах розробки стратегії і аналізу, й і ставить  основною метою створення точної й адекватної моделі інформаційних  потреб організації.

Розглянемо  коротко основні  властивості,  формальні позначення  й  визначення  сутностей, зв'язків, атрибутів.

Сутність — це реальний або уявлюваний  об'єкт інтересу, інформація про який підлягає збору або зберіганню. Графічно сутність представляється пойменованим прямокутником із закругленими кутами. Ім'я сутності дається в однині й пишеться заголовними буквами. Ім'я сутності  повинне бути таким, щоб представляти тип або клас об'єктів, а не окремий екземпляр. Будь-який  предмет або об'єкт може бути представлений тільки однією сутністю. Інакше кажучи, сутності завжди є  взаємовиключними.

Зв'язок — це деяка пойменована асоціація, що представляє інтерес, двох сутностей. Зв'язок є бінарним в тому розумінні, що це завжди асоціація в точності двох сутностей або сутності із самої собою. Кожний зв'язок має два кінці, для кожного з яких є свої:

•  ім'я;
•  ступінь/потужність;
•  факультативність — обов'язкова або факультативна.

Ці властивості використовуються для опису асоціації з кожної зі сторін, для завдання зв'язку повинні  бути визначені обидва її кінця.

У закінчення зі ступенем „багато” закінчення зв'язку з'єднується із прямокутником  у трьох точках. У закінчення зі ступенем „один” з'єднання здійснюється тільки в одній точці. Та половина зв'язку, що перебуває з боку обов'язкового її  кінця,  рисується суцільною  лінією, а та, що з факультативної сторони, —переривчастої.

При читанні зв'язку з обов'язкової  сторони  перед її  ім'ям використовуються слова  "у всіх випадках" або "завжди"; для факультативної сторони  використовуються слова "у загальному випадку" або "іноді". Ступінь "багато"  читається  як  "один або декілька", а ступінь "один" — "один і  тільки один".

Атрибут — це будь-яка деталь або аспект, що сприяють якісному або кількісному опису сутності, її  ідентифікації, класифікації або відбиттю її стану. Атрибутом може бути текст, число, картинка, почуття, запах. Загалом, усе, що потрібно. Займаючись обробкою даних, ми намагаємося в основному обмежитися  текстами й числами.

Для подання атрибута пишеться його ім'я малими літерами в однині, можливо, із прикладами значень. Атрибути  необов'язково  показувати  на діаграмі сутностей і зв'язків, однак додавання  до сутності одного-двох атрибутів  у період формування моделі, як правило, виявляється досить  корисним.

Атрибут описує одну сутність. Атрибут повинен описувати ту сутність, до якої він віднесений. У  кожний  момент  часу сутність може володіти лише одним значенням атрибута.

Атрибут, значення якого може бути відсутнім, називається факультативним. Він позначається символом "°" перед його ім'ям. Атрибут, значення якого повинне бути завжди відомо, називається обов'язковим, і позначається зірочкою "*" перед ім'ям. Обов'язковість означає, що сутність може бути визначена тоді й тільки тоді, коли відомі значення всіх її обов'язкових атрибутів. Всі атрибути унікального ідентифікатора повинні бути обов'язковими.

Кожна сутність повинна однозначно ідентифікуватися  за допомогою  деякої комбінації атрибутів і/або  зв'язків. Тому серед можливих атрибутів  сутності завжди повинні бути знайдені такі атрибути, які дозволяють неї  ідентифікувати. Унікальний ідентифікатор представляється на ER-Діаграмі вказівкою символу "#" перед ім'ям кожного атрибута, що входить у даний ідентифікатор. Значення усіх інших атрибутів повинні залежати від усього унікального ідентифікатора.

Дуже важливо чітко  розуміти, що всі визначення сутності, зв'язку, атрибута й унікального  ідентифікатора, які ми тільки що розглянули, суть визначення типу, або класу, поняття, а не екземпляра.  Екземпляри сутностей  і зв'язків будуть представлені в  самій базі даних..

3.2. Побудова  концептуальної моделі соціальної мережі

На основі проведеного  аналізу предметної області була побудована концептуальна модель з  використанням мови ER–моделювання. Концептуальна модель наведена на наступному рисунку. Декілька зауважень:

• По–перше, ця модель не містить опису атрибутів сутностей у зв’язку з відсутністю місця для їх зображення. Передбачається, що атрибути сутностей разом з їх властивостями (бізнес–правилами) детально описані на етапі аналізу.
• По–друге, мова ER–моделювання не передбачає детального представлення інформаційно–довідкових задач. Ми припускаємо, що вони мають звичайний текстовий опис, який представлений на етапі аналізу.
• По-третє, наша концептуальна модель не містить інших складових, а саме, докладний і строгий опис сховищ даних, та детальний опис потоків даних. Це не було зроблено, так як опис цих складових концептуальної моделі виходить за рамки курсової роботи.

4. ЛОГІЧНЕ ТА ФІЗИЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ

Завдання цього етапу  полягає у проведенні логічного  та фізичного проектування бази даних.

Логічне проектування бази даних. Процес створення моделі використовуваної на підприємстві інформації на основі вибраної моделі організації даних, але без урахування типу цільової СУБД і інших фізичних аспектів реалізації.

Другий етап проектування бази даних називається логічним проектуванням бази даних. Його мета полягає в створенні логічної моделі даних для досліджуваної частини підприємства. Концептуальна модель даних, створена на попередньому етапі, уточнюється і перетвориться в логічну модель даних. Логічна модель даних враховує особливості вибраної моделі організації даних в цільовій СУБД (наприклад, реляційна модель).

Якщо концептуальна модель даних не залежить від будь-яких фізичних аспектів реалізації, то логічна  модель даних створюється на основі вибраної моделі організації даних  цільової СУБД. Інакше кажучи, на цьому  етапі вже повинно бути відомо, яка СУБД використовуватиметься  як цільова — реляційна, мережева, ієрархічна або об'єктно-орієнтована. Проте на цьому етапі ігнорується  вся решта характеристик вибраної СУБД, наприклад, будь-які особливості  фізичної організації її структур зберігання даних і побудови індексів.

В процесі розробки логічна  модель даних постійно тестується і  перевіряється на відповідність  вимогам користувачів. Для перевірки  правильності логічної моделі даних  використовується метод нормалізації. Нормалізація гарантує, що відносини, виведені з існуючої моделі даних, не володітимуть надмірністю даних, здатною викликати порушення в процесі оновлення даних після їх фізичної реалізації. Крім всього іншого, логічна модель даних повинна забезпечувати підтримку всіх необхідних користувачам транзакцій.

Створена логічна модель даних є джерелом інформації для  етапу фізичного проектування і  забезпечує розробника фізичної бази даних засобами пошуку компромісів, необхідних для досягнення поставлених  цілей, що дуже важливе для ефективного  проектування. Логічна модель даних  виконує також важливу роль на етапі експлуатації і супроводу  вже готової системи. При правильно  організованому супроводі підтримувана в актуальному стані модель даних  дозволяє точно і наочно представити  будь-які зміни, що вносяться в  базу даних, а також оцінити їх вплив на прикладні програми і  використовування даних, що вже є  в базі. Фізичне проектування – це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.

Фізичне проектування бази даних. Процес підготовки опису реалізації бази даних на вторинних пристроях, що запам'ятовують; на цьому етапі розглядаються основні відносини, організація файлів і індексів, призначених для забезпечення ефективного доступу до даних, а також всі пов'язані з цим обмеження цілісності і засобу захисту.

Фізичне проектування є третім і останнім етапом створення проекту бази даних, при виконанні якого проектувальник ухвалює рішення про способи реалізації бази даних, що розробляється. Під час попереднього етапу проектування була визначена логічна структура бази даних (яка описує відносини і обмеження в даній прикладній області). Хоча ця структура не залежить від конкретної цільової СУБД, вона створюється з урахуванням вибраної моделі зберігання даних, наприклад реляційної, мережевої або ієрархічної. Проте, приступаючи до фізичного проектування бази даних, перш за все, необхідно вибрати конкретну цільову СУБД. Тому фізичне проектування нерозривно пов'язане з конкретною СУБД. Між логічним і фізичним проектуванням існує постійний зворотний зв'язок, оскільки рішення, що приймаються на етапі фізичного проектування з метою підвищення продуктивності системи, здатні вплинути на структуру логічної моделі даних.

Як правило, основною метою фізичного  проектування бази даних є опис способу  фізичної реалізації логічного проекту  бази даних. У разі реляційної моделі даних під цим мається на увазі  наступне:

• створення набору реляційних таблиць і обмежень для них на основі інформації, представленої в глобальній логічній моделі даних;
• визначення конкретних структур зберігання даних і методів доступу до них, забезпечуючих оптимальну продуктивність СУБД;
• розробка засобів захисту створюваної системи.

4.1. Логічне  проектування

У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.

Для перетворення концептуальної моделі, представленої у вигляді  мови ER–моделювання, у реляційну  модель, був використаний наступний  алгоритм.

• Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
• Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
• Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

Рис. Концептуальна ER-модель соціальної мережі

• Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори  кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
• Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

Повна логічна база даних  на основі концептуальної моделі з  урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.

Таблиця 1. Відношення сутності «Користувач»