Db design (ukr)

Softjourn Inc.

RDBMS Design

Anatoliy Okhotnikov
Softjourn Inc.

Про що буде йти мова
● Типи баз даних
● Реляційні бази даних (OLTP)
● Обробка транзакцій (ACID)
● Database-centric архітектура
● Моделювання даних. Узгодження іменування
● Нормалізація та денормалізація
● Індексування. Найкращі практики
● Посилання. Питання та обговорення

Про що не буде йти мова
● Нереляційні бази даних
● OLAP/структури підтримки прийняття рішень
● Інтенсивна теорія
● Інтенсивна практика

Типи баз даних
• Активна – event-driven, безпека статистика
• Хмара – доступ через веб-браузер або API
• Сховище – архів операційних, зовнішні дані
• Розподілена – модульна, багато як одна
• Документ-орієнтована – управління док-ами
• Вбудована – інтегрована у програму
• Федеративна(гетерогенна) – різні разом
• Граф – варіант NoSQL із структурами графу
• У-пам'яті – дуже швидка, знаходиться у пам'яті
• Знань – для управління знаннями, по темам
• Паралельна – покращення через паралелізацію

Copyright © 2000-2011 Softjourn, Inc. All rights reserved

Реляційні бази даних
• “A Relational Model of Data for
Large Shared Data Banks”, стаття
яку написав Edgar Frank "Ted"
Codd працюючи дослідницький
лабораторії IBM у San Jose.
• Обпублікована у
“Communications of the ACM” у
червні 1970 року
• Дослідницький проект Університету Каліфорнії
у Берклі – Berkley Ingress (1973)


Реляційні: початок


Реляційні: сьогодення


Обробка транзакцій (ACID)


Обробка транзакцій (ACID)
• Атомарність – результати транзакції або
повністю виконані, або повінстю відмінені.
• Узгодженість(цілісність) – перетворення з
одного вірного стану у інший вірний стан.
Транзакція вірна якщо вона не порушує
обмеження цілісності.
• Ізоляція – результати не видимі поки
транзакція не завершена.
• Довговічність(надійність) – після завершення
результати збережені у постійне сховище і
переживають наступні збої системи та носія.


Database-centric архітектура
Database- або data-centric
архітектура, це архітектура ПЗ у
якій база даних грає
суттєву(центральну) роль.
• Стандартна RDMBS (RAD)
• Динамічна, table-driven логіка
• Використання stored procedures
• Shared DB як засіб IPC


Database vs Application centric


Моделювання даних
При моделюванні ви визначаєте наступне
• Які елементи даних зберігати
• Яким великим може бути кожен елемент
• Яку інформацію може містити елемент
• Які елементи можна залишити пустими
• Які елементи обмежені певними рамками
• Чи і як пов'язані різні таблиці між собою


Моделювання даних
• Використовуйте
візуальні
інструменти
• Робіть реверс-
інженіринг
існуючої бази
• Перевіряйте та
будуйте зв'язки
• Працюйте
спільно


Узгодження іменування
• Joshua, Jana, John-David, Jill,
Jessa, Jinger, Josiah, Joy-
Anna, Jedidiah, Jeremiah,
Jason, James, Justin, Jackson,
Johannah, Jennifer
• Сім'я Duggar використовує
узгодження іменування
• Погана ідея для сім'ї
• Гарна ідея для бази даних
• Немає певних правил, просто слідуйте власній
угоді, яка вам зручна


Узгодження іменування — як?
• Оберіть одне і строго слідуйте йому:
camelCase, PascalCase, under_scores і т.д.
• Чому?
• Чистіший код
• Логічні з'єднання
• Психічне здоров'я вас та майбутніх
розробників
• Явно називайте обмеження (constraints)
• Не використувуйте ключові слова як імена
стовбців


Нормалізація
Ключ, Повний ключ, і нічого крім
ключа. Допоможи мені Кодде.


Нормалізація та денормалізація
• Процес зміни дизайну бази даних
для створення схеми таблиць у
нормалній формі.
• Нормальні форми: 1NF, 2NF, 3NF,
EKNF, BCNF, 4NF, 5NF, DKNF,
6NF для OLTP (онлайн обробки
транзакцій) швидкі із сталим
станом
• NF2 або N1NF для OLAP(онлайн
обробка аналітики) часто
вимагає денормалізації для
прискорення

Не нормалізований набір


Нормалізований набір


Навіщо нормалізувати?
• Запобігаємо дублюванню даних
• Дозволяємо користувачам робити
власні зміни
• Запобігаємо аномальності даних
• Інструменти третіх сторін очікують
нормалізовані дані
• Іноді треба де-нормалізовувати,
але уникайте ранньої оптимізації


Індексування
Знайдіть книжку Ван Пельта без
каталогу. Будьласка.


Типи індексів
• Unique – гарантує що ключ індексування є
не містить дубльованих даних
• Full-text – використовується для
індексування великої кількості тексту
• Included columns – дозволяє додати
неключові стовбчики
• Indexed views – зберігає у базі,
використовує оптимізатор
• XML – властивості, атрибути та елементи
• Filtered – фільт по існуючому індексу
• Spatial – геометричний або географічний
• Інші...

Індексування: основні ключі
Основний ключ (primary key)
==
унікальний індекс


Зауваження індексування: таблиці
Цілочислений основний ключ у
кожній таблиці

SELECT s.term, s.section_id, COUNT(penn_id)
FROM flat_section s JOIN flat_enrollment e
ON s.section_id = e.section_id AND s.term =
e.term GROUP BY s.term, s.section_id


Зауваження індексування: таблиці
• Чому цілочисельні ключі?
• Вузькі індекси = більше індексних рядків на
сторінку = меньше сторінок = меньше
читань
• Вузькі чисельні індекси = більш ефективні
join'и
• Можуть допомогти у відновленні після
спотворення даних
• Сурогатні (не з даних програми) ключі більш
стійкі до майбутнього ніж натуральні ключі
– Дозволяють зміну асоційованих полів
– Не чутливі до зовнішніх змін даних
– Більш гнучкі для майбутніх змін (архів)

Зауваження індексування: стовбці


Зауваження індексування: стовбці
• Зєднання стовбців: індексовані
цілочисельні значення – ти друг!
• Як стовбці використовуються у запитах?
• Відношення: 1-до-1, 1-до-багатьох,
багато-до-багатьох
• Тип даних
• Індексування багатьох стовбців: в міру
• Ціль №1: швидкодія!
• Ціль №2: якнайменьший індексний файл


Найкращі практики: типи даних
• Беріть до уваги
довжину стовбчика
• Знайте необхідний
рівень точності
• Залиште собі простір
для росту
• Відповідність до дня,
хвилини,
мілісекунди?

Найкращі практики: видалення
• Логічне проти фізичного


Найкращі практики: навантажуйте базу
• Коли це має сенс – дозвольте
базі працювати за вас
• Зовнішні ключі
• Унікальні індекси
• Перевірочні обмеження
• Обмеження за замовчуванням
• Трігери


Найкращі практики: master tables
• Вони усюди:
• Звіти
• Інтерфейси
• Пошуки
• і т.д.

• Засіб для одночасного впровадження
нормалізації та індексування
• Компоненти надійної мастер таблиці:
• Сурогатні ключі
• Внутрішній код/назва (не міняється)
• Опис для публічного перегляду (міняється)
• Дата створення та оновлення

Найкращі практики: час жувати!
• “Тимчасові”
проекти
• Балансуйте між
сьогоднішнім
прагматизмом та
завтрашнім болем
• Робіть code review
швидше

Найкращі практики: експериментуйте
• Експерементуйте
з вашою базою та
запитами для
покращення часу
та планів
виконання


Найкращі практики: будьте впевнені!
• Клопочіться про фідбек по дизайну бази,
радше ніж по кодінг стандарту
• Питайте думку інших та діліться власними
думками!
• Більше очей = кращий дизайн бази даних
• Більше ідей = кращий дизайн бази даних


Гумор


Посилання
• http://en.wikipedia.org/wiki/Database
• http://db.cs.berkeley.edu/papers/fntdb07-
architecture.pdf
• http://philip.greenspun.com/sql/index.html
• http://www.swegler.com/becky/blog/wp-
content/uploads/2009/10/wcit-techtalk-database-
design.pdf
• http://en.wikipedia.org/wiki/Database-
centric_architecture
• http://michaeljswart.com/2011/01/ridiculously-
unnormalized-database-schemas-part-one/
•
•Copyright © 2000-2011 Softjourn, Inc. All rights reserved

Питання та обговорення
“Анатолій Охотніков”
<aokhotnikov@softjourn.com>


Db design (ukr)

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (15)

Similar to Db design (ukr)

Similar to Db design (ukr) (20)

Db design (ukr)