1. Взаємозв'язок між оригінальним документом і суб'єктом
Це можуть бути стосунки один на один, один до багатьох і багато-на-багато. Загалом, це стосунки один до одного: тобто пара оригінальних документів
повинна і відповідати лише одній сутності. У особливих випадках це можуть бути відношення один до багатьох або багато до одного, тобто один оригінальний документ відповідає кільком реальностям
тіло або кілька оригінальних документів, що відповідають певній сутності. Сутність тут можна розуміти як базову таблицю. Після уточнення цієї відповідності — проєктуйте для нас
Інтерфейс входу дуже корисний.
〖Приклад 1〗: Інформація про резюме працівника відповідає трьом основним таблицям у системі інформації з управління персоналом: базова таблиця інформації працівника та суспільство
Таблиця стосунків, форма резюме на роботі. Це типовий приклад «один оригінальний документ відповідає кільком сутностям».
2. Первинні та зовнішні ключі
Загалом, суб'єкт не може мати ні первинного, ні зовнішнього ключа. На діаграмі E-R об'єкти в листковій частині можуть визначати первинний ключ,
Також можливо не визначати первинний ключ (оскільки він не має дітей), але він повинен мати зовнішній ключ (оскільки має батька).
Проєктування первинних і зовнішніх ключів займає важливе місце у проєктуванні глобальних баз даних. Коли проєктування глобальної бази даних завершено, виникає
Американські експерти з проєктування баз даних сказали: «Ключі, ключі всюди, лише ключі», це його досвід у проєктуванні баз даних
Вона також відображає його надзвичайно абстрактні уявлення про суть інформаційних систем (моделей даних). Тому що: первинний ключ — це дуже абстрактна сутність, а первинний ключ пов'язаний з
Пара зовнішніх ключів, що представляють зв'язок між сутностями.
3. Природа базової таблиці
Базова таблиця відрізняється від проміжної та тимчасової таблиці тим, що має такі чотири характеристики:
(1) Атомарність. Поля в базовій таблиці більше не розкладаються.
(2) Примітивність. Записи в базовій таблиці — це записи оригінальних даних (базових даних).
(3) Дедуктивно. Усі вихідні дані можна отримати з даних у базовій таблиці та кодовій таблиці.
(4) Стабільність. Структура базової таблиці є відносно стабільною, і записи в таблиці слід зберігати довго.
Після розуміння природи базових таблиць, при проектуванні баз даних базові таблиці можна відрізнити від проміжних і тимчасових таблиць.
4. Стандарти парадигми
Взаємозв'язок між базовою таблицею та її полями має максимально відповідати третій парадигмі. Однак дизайни баз даних, які відповідають третій парадигмі, часто не відповідають
Найкращий дизайн. Для підвищення операційної ефективності баз даних часто необхідно знизити стандарт парадигми: відповідно збільшити резервність для досягнення простору в часі
Мета.
Приклад 2: Існує базова таблиця зберігання товарів, як показано в Таблиці 1. Наявність поля «Кількість» вказує, що таблиця не розроблена для виконання
Третя парадигма достатня, оскільки «кількість» можна отримати, помноживши «одиничну ціну» на «кількість», що вказує, що «кількість» є надлишковим полем. Однак зростання
Резервне поле «кількість» може покращити швидкість виконання статистики запитів, тобто практики обміну простору на час.
У Rose 2002 існує два типи закріплених стовпців: стовпці даних і обчислені стовпці. Стовпець, подібний до «суми», називається «стовпцем обчислень», і
Стовпці, такі як «Ціна одиниці» та «Кількість», називаються «стовпцями даних».
Таблиця 1 Структура таблиці товарів
Назва продукту Модель продукту Ціна одиниці Кількість
ТБ 29 дюймів 2 500 40 100 000
5. Розумійте три парадигми простими словами
Розуміння трьох парадигм простими словами є великою перевагою для проєктування баз даних. У проєктуванні баз даних, щоб краще застосувати три парадигми, просто
Три парадигми слід розуміти простою мовою:
Перша парадигма: 1NF — це атомарне обмеження атрибутів, яке вимагає, щоб атрибути були атомарними і більше не можуть розкладатися;
Друга парадигма: 2NF — це обмеження унікальності записів, яке вимагає, щоб записи мали унікальну ідентифікацію, тобто унікальність сутності;
Парадигма 3: 3NF — це обмеження на надлишковість полів, тобто жодне поле не може бути виведене з інших полів, воно вимагає, щоб поле не було надлишковим
。
Жоден резервний дизайн бази даних не може цього зробити. Однак база даних без резервування не обов'язково є найкращою базою даних, іноді для покращення удачі
Для досягнення ефективності необхідно знизити стандарт парадигми та належним чином зберегти резервні дані. Конкретний підхід полягає у дотриманні третьої парадигми при розробці концептуальних моделей даних
, робота зі зменшення стандарту парадигми розглядається при проєктуванні фізичної моделі даних. Зниження парадигми — це додавання полів, які дозволяють резервувати.
6. Вмійте добре розпізнавати та правильно поводитися з відносинами «багато до багатьох»
Якщо існує взаємозв'язок між двома суб'єктами, цей зв'язок слід усунути. Спосіб усунути це — додати третину реалу між цими двома
Тіло. Таким чином, те, що раніше було стосунками «багато до багатьох», тепер перетворилося на дві стосунки «один на багатьох». Атрибути двох оригінальних сутностей мають бути розподілені розумно
Перейдіть до трьох сутностей. Третя сутність тут — це, по суті, більш складне відношення, яке відповідає базовій таблиці. Загалом, цифри
Інструмент проєктування бібліотек не може розпізнавати співвідношення багато до багатьох, але може обробляти співвідношення «багато до багатьох».
Приклад 3: У «Системі бібліотечної інформації» «книга» є сутністю, а «читач» також є сутністю. Ці дві сутності — одне й те саме
Взаємозв'язок між книгами — типовий «багато до багатьох»: книгу можуть позичати кілька читачів у різний час, а один читач — більше
Ця книга. З цією метою слід додати третю сутність між цими двома організаціями, яка називається «книги, що позичають і повертають», і її властивості: час позики та позичання
Вона також має логотип (0 означає позичання книги, 1 — повернення книги), крім того, має бути два зовнішніх ключі (первинний ключ від «книга» та первинний ключ «читач»), щоб
Вона пов'язана з «книгами» та «читачами».
7. Метод значення первинного ключа PK
PK — це інструмент міжтаблицевого з'єднання для програмістів, який може бути рядком чисел без фізичної значущості, який автоматично додається програмою до 1. Так
є фізично значущою назвою поля або комбінацією назв полів. Але перше краще за друге. Коли PK — це комбінація назв полів, запропонуйте номер поля
Не рахуйте надто багато, адже індекс не лише займає багато місця, а й сповільнюється.
8. Правильно налаштуйте надлишковість даних
Повторення первинних і зовнішніх ключів у кількох таблицях не є поняттям надлишковості даних, і багато людей про це не знають
。 Повторення неключових полів — це надлишковість даних! І це низькорівнева надлишковість, тобто повторювана надлишковість. Розширена надлишкова система не базується на полі
Багаторазово, але похідні від полів.
Приклад 4: Три поля «ціна одиниці, кількість і кількість» у продукті, «кількість» утворюється з «одиничної ціни», помноженої на «кількість»
Це надлишковість, і це свого роду просунута надлишковість. Мета резервування — підвищити швидкість обробки. Лише низькорівневе надлишкове навантаження збільшить кількість
неузгодженість даних, оскільки одні й ті ж дані можуть вводитися кілька разів з різних часів, місць і ролей. Тому ми виступаємо за розширену надлишковість (pie
надлишковість за своєю природою), і виступає проти низькорівневої надлишковості (повторюваної надлишковості).
9. Не існує стандартної відповіді для діаграм E--R
Не існує стандартної відповіді на діаграму E-R інформаційної системи, оскільки її метод проєктування та малювання не є унікальними, якщо вони охоплюють бізнес, необхідний системі.
Обсяг і функціональний зміст цілком можливі. Натомість необхідно змінити діаграму E-R. Хоча вона не має єдиної стандартної відповіді, це не означає, що вона може бути довільною
Дизайн. Критерії хорошої E-R-діаграми: чітка структура, лаконічна асоціація, помірна кількість сутностей, розумний розподіл атрибутів і відсутність низькорівневої надлишковості.
10. Техніки перегляду корисні для проєктування баз даних
На відміну від базових таблиць, кодових таблиць і проміжних таблиць, представлення — це віртуальні таблиці, які залежать від реальних таблиць джерела даних для існування. Огляди — для програмістів
Вікно з базою даних — це форма синтезу даних базової таблиці, метод обробки даних і своєрідний вид конфіденційності даних користувачів
означає. Для виконання складної обробки, збільшення швидкості обчислень і економії місця для зберігання глибина визначення зображення зазвичай не повинна перевищувати три шари. Десь три поверхи
Якщо перегляду все одно недостатньо, слід визначити тимчасову таблицю на вигляді, а потім — на тимчасовій таблиці. Таким чином, глибина огляду визначається неодноразово
Жодних обмежень.
Для певних інформаційних систем, пов'язаних із національними політичними, економічними, технологічними, військовими та безпековими інтересами, роль поглядів є ще важливішою. Ці
Після завершення фізичного проєктування базової таблиці системи перший шар переглядів одразу встановлюється на базовій таблиці, і кількість та структура цього вигляду збігаються з базовою таблицею
Кількість і структура абсолютно однакові. І встановлено, що всі програмісти мають право працювати лише на екрані. Лише адміністратор бази даних, з
«Ключ безпеки», який тримає кілька співробітників, можна керувати безпосередньо на базовому столі. Читачам пропонують задуматися: чому так?
11. Проміжні таблиці, оператори та тимчасові таблиці
Проміжна таблиця — це таблиця, яка зберігає статистику, призначена для зберігання даних, звітів або результатів запитів, і іноді не має первинного ключа з
зовнішні ключі (крім сховищ даних). Тимчасові таблиці розробляють програмісти для зберігання тимчасових записів для особистого користування. Базові та проміжні таблиці підтримуються DBA
Тимчасові таблиці автоматично підтримуються самим програмістом.
12. Обмеження цілісності проявляються у трьох аспектах
Цілісність домену: використовуйте Check для реалізації обмежень, а в інструменті проектування бази даних при визначенні діапазону значень поля є Ch
Кнопка ECK, за допомогою якої визначається місто значення поля.
Референтна цілісність: реалізовано з тригерами на рівні PK, FK та таблиці.
Цілісність, визначена користувачем: це деякі бізнес-правила, які реалізуються за допомогою збережених процедур і тригерів.
13. Метод запобігання патченню дизайну баз даних — це принцип «на три менше»
(1) Чим менше таблиць у базі даних, тим краще. Лише якщо зменшити кількість таблиць, можна сказати, що діаграма E-R системи є маленькою і тонкою, і її видаляють
Дубльовані та надлишкові сутності формують високий ступінь абстракції об'єктивного світу, і систематична інтеграція даних здійснюється для запобігання проєктуванню патчів;
(2) Чим менше полів у таблиці, що поєднують первинні ключі, тим краще. Через роль первинного ключа один із них — побудувати індекс первинного ключа, а інший — слугувати підтаблицею
зовнішні ключі, тому кількість полів у комбінації первинних ключів зменшується, що не лише економить час виконання, а й зберігає місце в індексі;
(3) Чим менше полів у таблиці, тим краще. Лише невелика кількість полів вказує на відсутність дублювання даних у системі
Надлишковість даних мінімальна, і, що важливіше, читачам рекомендується навчитися «змінювати рядки», що запобігає потраплянню полів у основну таблицю підтаблиці
, залишаючи багато вільних полів у головній таблиці. Так званий «рядок зміни стовпців» полягає у виділенні частини вмісту основної таблиці та створенні окремої
Підтаблиця. Цей метод дуже простий, деякі люди просто не звикають до нього, не приймають і не впроваджують.
Практичний принцип проєктування баз даних полягає у пошуку правильного балансу між надлишковістю даних і швидкістю обробки. «Три менше» — це цілісний огляд
Думка, всеохопні погляди не можуть ізолювати певний принцип. Принцип відносний, а не абсолютний. Принцип «ще троє» однозначно помилковий. Спробуй
Подумайте: якщо покривати ту ж функцію системи, то діаграма E-R зі 100 сутностями (загалом 1 000 атрибутів) безумовно краща за діаграму E--R з 200 сутностями (загалом 2 000 атрибутів)
Діаграма E-R набагато краща.
Пропагування принципу «трьох менше» полягає в тому, щоб дозволити читачам навчитися використовувати технологію проєктування баз даних для систематичної інтеграції даних. Кроки для інтеграції даних мають застосувати:
Файлова система інтегрована у базу даних додатків, база даних застосунків інтегрована у тематичну базу даних, а тематична база інтегрується у глобальну комплексну базу даних.
Чим вищий ступінь інтеграції, тим сильніший обмін даними і тим менше інформаційних островів присутній
Кількість первинних ключів і кількість атрибутів будуть меншими.
Мета просування принципу «трьох менше» полягає в тому, щоб завадити читачам використовувати технології патчування для постійного додавання, видалення та модифікації бази даних, щоб створювати корпоративні дані
Бібліотека перетворилася на «купу сміття» з довільно спроектованих таблиць баз даних або «хаос» таблиць баз даних, і зрештою спричиняє базові таблиці та генерації в базі даних
Кодові таблиці, проміжні та тимчасові таблиці перевантажені і безліч, що призводить до неможливості підтримувати та паралізувати інформаційні системи підприємств і установ.
Принцип «ще три варіанти» може застосовувати будь-хто, що є помилкою «патчового методу» для проєктування баз даних. Принцип «трьох менше»
Це принцип «менше, але добре», що вимагає високих навичок проєктування баз даних і мистецтва, що не кожен може робити, бо цей принцип усувається
Теоретична основа для проєктування бази даних із використанням «методу патчування».
14. Шляхи підвищення ефективності роботи бази даних
За заданих апаратних і програмних умов системи методи підвищення ефективності роботи системи баз даних такі:
(1) У фізичному дизайні бази даних зменшити парадигму, збільшити резервність, використовувати менше тригерів і більше збережених процедур.
(2) Коли обчислення дуже складне, а кількість записів дуже велика (наприклад, 10 мільйонів), складний розрахунок спочатку має бути поза базою даних
Після того, як метод файлової системи обчислюється та обробляється мовою C++, він нарешті додається до таблиці. Це досвід проєктування телекомунікаційних білінгових систем.
(3) Якщо в таблиці виявлено забагато записів, наприклад, понад 10 мільйонів, таблицю слід розділити горизонтально. Практика горизонтальної сегментації полягає в наступному:
Розділіть запис таблиці горизонтально на дві таблиці на основі певного значення первинного ключа PK таблиці. Якщо в таблиці виявлено забагато полів, наприклад,
Вісімдесят — стіл поділений вертикально, а оригінальний стіл поділений на два столи.
(4) Оптимізація системи управління базами даних СУБД, тобто оптимізація різних параметрів системи, таких як кількість буферів.
(5) При використанні мови SQL, орієнтованої на дані, намагайтеся впроваджувати алгоритми оптимізації.
Коротко кажучи, для підвищення ефективності роботи бази даних необхідно оптимізувати систему баз даних, її проєктування та реалізацію програми
, ці три рівні працюють наполегливо одночасно.
Вищезазначені чотирнадцять навичок поступово узагальнюються багатьма людьми у багатьох практиках аналізу та проєктування баз даних. Для цих досвідів
Читачі не повинні бути жорсткими чи шаблонними, а повинні засвоювати і розуміти, шукати правду у фактах і опановувати гнучко. І поступово робіть: надсилайте заявку
виставка, застосування у розробці.
|
Опубліковано 09.04.2015 21:00:54
|
|
|
